绕过pip卸载的确认提示
我正在尝试卸载超级用户环境中的所有 django 软件包,以确保所有 webapp 依赖项都安装到我的 virtualenv 中。
sudo su
sudo pip freeze | grep -E '^django-' | xargs pip -q uninstall
但是pip想要确认每个包的卸载,并且pip似乎没有-y
选项。有没有更好的方法来卸载一批python模块? rm -rf .../site-packages/ 是正确的方法吗?有 Easy_install 替代方案吗?
或者,最好强制 pip 将所有依赖项安装到 virtualenv,而不是依赖系统 python 模块来满足这些依赖项,例如 pip --upgrade install,但甚至强制平等要安装旧版本以覆盖任何系统模块。我尝试激活我的 virtualenv,然后 pip install --upgrade -rrequirements.txt
,这似乎安装了依赖项,甚至是我的系统路径中存在的依赖项,但我无法确定这是否是因为我的系统模块很旧。并且 man pip
似乎并不能保证这种行为(即安装系统站点包中已存在的包的相同版本)。
I'm trying to uninstall all django packages in my superuser environment to ensure that all my webapp dependencies are installed to my virtualenv.
sudo su
sudo pip freeze | grep -E '^django-' | xargs pip -q uninstall
But pip wants to confirm every package uninstall, and there doesn't seem to be a -y
option for pip. Is there a better way to uninstall a batch of python modules? Is rm -rf .../site-packages/
a proper way to go? Is there an easy_install alternative?
Alternatively, would it be better to force pip to install all dependencies to the virtualenv rather than relying on the system python modules to meet those dependencies, e.g. pip --upgrade install
, but forcing even equally old versions to be installed to override any system modules. I tried activating my virtualenv and then pip install --upgrade -r requirements.txt
and that does seem to install the dependencies, even those existing in my system path, but I can't be sure if that's because my system modules were old. And man pip
doesn't seem to guarantee this behavior (i.e. installing the same version of a package that already exists in the system site-packages).
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(7)
从 pip 版本 7.1.2 开始,您可以运行
pip uninstall -y
或从文件
starting with pip version 7.1.2 you can run
pip uninstall -y <python package(s)>
or from file
Pip 不包含 --yes 选项(从 pip 版本 1.3.1 开始)。
解决方法:通过管道传递“yes”!
Pip does NOT include a --yes option (as of pip version 1.3.1).
WORKAROUND: pipe yes to it!
如果您想卸载
requirements.txt
中的每个软件包,If you want to uninstall every package from
requirements.txt
,在 www.saturncloud.io 上,Jupiter 笔记本可以这样使用:
on www.saturncloud.io, Jupiter notebooks one can use like this:
是的。不要过多地乱用内置的系统安装包。许多系统软件包,特别是 OS X 中的软件包(甚至是 debian 及其派生版本)都过于依赖它们。
如果 venv 中安装了更多已经存在于系统软件包中的软件包,那么这应该不是什么大问题,特别是如果它们是不同版本的话。这就是 virtualenv 的全部意义。
不,它不会安装主安装中已有的软件包,除非您使用
--no-site-packages
标志来创建它,或者所需的版本和当前的版本不同。Yes. Don't mess too much with the inbuilt system installed packages. Many of the system packages, particularly in OS X (even the debian and the derived varieties) depend too much on them.
It should not be a big deal if there are a few more packages installed within the venv that are already there in the system package, particularly if they are of different version. Thats the whole point of virtualenv.
No, it doesn't install the packages already there in the main installation unless you have used the
--no-site-packages
flag to create it, or the required and present versions are different..可以绕过确认
can bypass confirm
Lakshman Prasad 是对的,
pip --upgrade
和/或virtualenv --no-site-packages
是正确的选择。卸载系统范围的 python 模块是不好的。pip 的
--upgrade
选项确实会在虚拟环境中安装所需的模块,即使它们已经存在于系统环境中,并且即使所需版本或最新可用版本与系统版本相同。而且,在创建虚拟环境时使用 --no-site-packages 选项可确保系统路径中缺少模块的存在不会掩盖缺少的依赖项。这有助于暴露模块从一个包迁移到另一个包期间的问题,例如 pinax.apps.groups -> django-groups,特别是当问题出在 django 中的 load templatetags 语句时,该语句在所有可用模块中搜索 templatetags 目录及其中的标签定义。
Lakshman Prasad was right,
pip --upgrade
and/orvirtualenv --no-site-packages
is the way to go. Uninstalling the system-wide python modules is bad.The
--upgrade
option to pip does install required modules in the virtual env, even if they already exist in the system environment, and even if the required version or latest available version is the same as the system version.And, using the --no-site-packages option when creating the virtual environment ensures that missing dependencies can't possibly be masked by the presence of missing modules in the system path. This helps expose problems during migration of a module from one package to another, e.g. pinax.apps.groups -> django-groups, especially when the problem is with load templatetags statements in django which search all available modules for templatetags directories and the tag definitions within.