Pip: `pip install -U`升级已经满足依赖性

创建于 2011-06-09  ·  23评论  ·  资料来源: pypa/pip

如果我pip install -U foo ,我希望将安装foo的最新版本,并且仅在不满意foo的依赖项时才重新安装它们。 但是实际上,即使我已经安装了相同的版本,也都将重新安装所有依赖项:


$ pip install -U django-supervisor
Downloading/unpacking django-supervisor
  Downloading django-supervisor-0.2.0.tar.gz
  Running setup.py egg_info for package django-supervisor
Downloading/unpacking supervisor (from django-supervisor)
  Downloading supervisor-3.0a10.tar.gz (438Kb): 438Kb downloaded
  Running setup.py egg_info for package supervisor
    no previously-included directories found matching 'docs/*.pyc'
    no previously-included directories found matching 'docs/.build'
Downloading/unpacking meld3>=0.6.5 (from supervisor->django-supervisor)
  Downloading meld3-0.6.7.tar.gz
  Running setup.py egg_info for package meld3
Installing collected packages: django-supervisor, supervisor, meld3
  Found existing installation: django-supervisor 0.1.1
    Uninstalling django-supervisor:
      Successfully uninstalled django-supervisor
  Running setup.py install for django-supervisor
  Found existing installation: supervisor 3.0a10
    Uninstalling supervisor:
      Successfully uninstalled supervisor
  Running setup.py install for supervisor
    no previously-included directories found matching 'docs/*.pyc'
    no previously-included directories found matching 'docs/.build'
    Skipping installation of /usr/local/ejucovy/django/lib/python2.6/site-packages/supervisor/__init__.py (namespace package)
    Installing /usr/local/ejucovy/django/lib/python2.6/site-packages/supervisor-3.0a10-py2.6-nspkg.pth
    Installing echo_supervisord_conf script to /usr/local/ejucovy/django/bin
    Installing pidproxy script to /usr/local/ejucovy/django/bin
    Installing supervisorctl script to /usr/local/ejucovy/django/bin
    Installing supervisord script to /usr/local/ejucovy/django/bin
  Found existing installation: meld3 0.6.7
    Uninstalling meld3:
      Successfully uninstalled meld3
  Running setup.py install for meld3
Successfully installed django-supervisor supervisor meld3
Cleaning up...

我的supervisor-3.0a10meld3-0.6.7 “现有安装”都“成功卸载”,然后安装了相同的版本。

upgrade auto-locked bug

最有用的评论

我认为这不是#49的重复。 我读#49时说的是install -U foo不应该重新安装_ foo本身_如果已经是最新版本了-这与是否应该重新安装foo的已经满足的依赖关系。

对于具有频繁发布但相当稳定的API的难以构建的库来说,这种区别很重要-在大多数情况下,一个安装就足够了-我只想在我的依赖项开始使用那些更新的功能时重新安装它嵌套的依赖关系(即,如果不再满足要求)-例如:

  • foo 0.1取决于lxml>=2.3.0
  • foo 0.2已发布,并且取决于lxml>=2.3.0 (相同的依赖项)
  • lxml 2.4.0被释放

如果我已经安装了foo 0.1lxml 2.3.0 ,并且我已经安装foo 0.1 pip install -U foo ,则不要安装lxml 2.4.0 。 仅当foo开始依赖lxml>=2.4.0时,才应安装lxml 2.4.0 lxml>=2.4.0

所有23条评论

根据我的判断,这是已知的行为,不知道它是否真的是一个错误-我猜easy_install具有相同的行为。

我想听听别人的意见。

PS .: StackOverflow中有一个与此相关的问题: http :

相关问题49

这是一个错误,并且是#49的重复项。

我认为这不是#49的重复。 我读#49时说的是install -U foo不应该重新安装_ foo本身_如果已经是最新版本了-这与是否应该重新安装foo的已经满足的依赖关系。

对于具有频繁发布但相当稳定的API的难以构建的库来说,这种区别很重要-在大多数情况下,一个安装就足够了-我只想在我的依赖项开始使用那些更新的功能时重新安装它嵌套的依赖关系(即,如果不再满足要求)-例如:

  • foo 0.1取决于lxml>=2.3.0
  • foo 0.2已发布,并且取决于lxml>=2.3.0 (相同的依赖项)
  • lxml 2.4.0被释放

如果我已经安装了foo 0.1lxml 2.3.0 ,并且我已经安装foo 0.1 pip install -U foo ,则不要安装lxml 2.4.0 。 仅当foo开始依赖lxml>=2.4.0时,才应安装lxml 2.4.0 lxml>=2.4.0

嗯,是的,有点不同。 即使#49是固定的,当依赖项不是最新版本,但仍满足依赖项要求时,仍需要一些其他代码来实现所需的行为。

我认为,如果我们进行了更改,某些人会感到惊讶。 我可以看到为什么在某些情况下是理想的-但我也可以看到当前行为(负49)更可取的情况。 所以我在这个栅栏上。

额外的命令行选项是否合适? pip install foo --upgradepip install foo --upgrade-recursive ? (或者--upgrade-nonrecursive如果保持向后兼容的当前行为很重要)

默认情况下使升级为非递归升级将与其他软件包管理器(例如APT和Portage)保持一致。 而且我认为这种行为有一个很好的理由,那就是它避免了意外的副作用-如果我想升级软件包P,那么我想沿着upgrade P输入命令,不是upgrade P --but-not-other-things

另一方面,我认为默认情况下“ upgrade all”命令(请参阅#59)应该是递归的,因为默认情况下“ all”实际上意味着“ all”。 在这种情况下,非递归行为将意味着“升级直接安装的所有软件包,但不升级未直接安装的任何依赖项”(例如Portage的emerge --update @world而没有--deep )。

一个相关的问题是,如果要升级的软件包依赖于另一个已安装但无法从存储库中获取的软件包,则Pip将失败并且无法升级请求的软件包,即使已满足其依赖性。

这似乎与-I和-U一起发生。

由于-I代表--ignore-installed ,并且旨在使pip像当前未安装任何东西一样工作,因此重新安装所有内容是-I的正确行为。 因此,这里的行为仅是-U的错误,而不是-I

easy_install没有相同的行为。 如果已经满足,easy_install将不会重新安装依赖关系。

这不是功能或行为,这是一个错误。

这也确实很烦人-测试框架程序包的PIP分发或更新单个框架附件,意味着需要重新安装整个框架及其所有依赖项。 这些不必要的下载和安装浪费了时间和资源。

对于那些只想_now_的人,只需将行为/代码更改为“ -U”

我认为这可以达到预期的效果,对吗?

仅升级顶级要求:

  • pip install -U --no-deps REQS //仅升级顶层
  • pip install REQS //第二遍将安装升级中的所有_new_依赖项

对于最简单的情况就足够了,但是我认为这不适用于Requirements.txt文件,或者如果有依赖项对其install_requires进行了更新。 我们有一个复杂的脚本,它与我们的requirements.txt有所不同,或多或少地完成了您所描述的内容,但它无法处理> 1的升级深度。

在一定程度上使事情变得复杂的是,许多django软件包由于此bug注释掉了或删除了它们的install_requires行。 否则,他们最终会安装一些Alpha版本的django(这是我们的经验,我已经在许多著名的django软件包的github问题中看到了它。

@fdintino ,我用需求-U和--no-deps

对于顶级需求具有新的“ install_requires”依赖性的情况,这就是为什么我提到了第二次安装命令的原因。

对于“存在依赖项,其install_requires有更新”的情况,我不确定是否在那儿关注您。 如果您想进行完整的递归升级,您只会发现并希望对此采取行动,对吗?

仅当您不再满足要求时。 因此,例如,如果我更新了django-sentry,而django-sentry需要django-celery>=2.5.4,django-celery<3.0 ,而以前需要django-celery>=2.5.3,django-celery<3.0 (可能是由于错误修复或新功能),而我目前拥有django-celery==2.5.3 ,那么我希望它可以更新django-celery来满足要求,就像我的补丁一样。 但是,如果我碰巧有django-celery==2.5.4我不会指望它会更新芹菜。 在celery的情况下,这没什么大不了的,但是当程序包中有Django>1.2,Django<=1.4 ,并且项目通常针对Django 1.2、1.3或1.4编写时,django的意外升级可能会令人头疼。

谢谢@fdintino 。 我现在关注。 您不想切断所有递归行为(将进行必要的升级以满足要求),而只是想停止递归“强制”升级。

顺便说一句,您的评论由于格式而被裁剪。 可能想为其他人解决。

我发布了一个要点,该要点按上述顺序使用2条命令分解了所需的行为。
并不是说这会使对这张票或拉票的渴望无效,但对我确定如何
它目前可以使用,目前还可以使用。
(提示:在示例中,“ b”是与django的相似之处,被提及为关注点)

https://gist.github.com/3088149

如果不是这种情况,请根据要点发表评论。

我注意到这已经开放很长时间了。

我发现我的pip版本现在可以选择执行

pip install --upgrade --upgrade-strategy=only-if-needed package

尽管很冗长,但这似乎是期望的行为。 我个人认为如果将其作为默认值会很棒,但是现在更改为时已晚。

如果现在更改默认值为时已晚,那么我认为可以将其关闭吗?

https://github.com/pypa/pip/issues/3871#issuecomment -247789343中,我提到了我认为是我们将继续前进的方式,在此复制:

现在转回此。 我认为这是我们应该做的:

  1. 在pip vX中添加--upgrade-strategy = [eager / non-eager](默认为eager ,并允许人们选择采用非渴望策略。 这将使我们能够从人们那里获得一些现实世界的测试,而无需立即对每个人进行更改。
  2. 解决了来自1的任何反馈后,请在pip vX + 1中将默认值--upgrade-strategy切换non-eager 。 通过强制每个人进行更改,这将使我们在现实世界中得到更多使用,但是对于由于某种原因而被更改破坏的人,则可以逃脱。
  3. 解决了来自2的任何反馈后,请看一下在pip vx + 2中弃用--upgrade-strategy (按照我们的常规弃用策略将其删除)。

在不急于将其设置为默认值之前,这将有较长的交付时间,但它使我们可以更慢地逐步调整它,以确保没有一些用例可以避免这种情况。 理想情况下,我认为我们希望最终摆脱--upgrade-strategy标志。 这种标记感觉就像是在问问题,因为它本质上要求我们重复进行升级测试以真正完全测试事物。 我确实认为这是现在添加的一个很好的标记,以允许分阶段处理任何损坏。

听起来不错,我将等待步骤2完成。 似乎其他问题是重复的,但已经关闭。

@xavfernandez @dstufft是否可以将其关闭,或者我们要等到默认开关吗?

我们可能要等到默认开关。

由于#4500被合并而关闭

此页面是否有帮助?
0 / 5 - 0 等级