将共享 python 包添加到多个 virtualenv

发布于 2024-09-18 08:52:31 字数 2067 浏览 7 评论 0 原文

当前的Python工作流程

我有pip分发virtualenvvirtualenvwrapper 安装到我的 Python 2.7 站点包中(Mac OS X 上的 Python 框架安装)。在我的 ~/.bash_profile 中,我有一行

export PIP_DOWNLOAD_CACHE=$HOME/.pip_download_cache

This 给出了如下工作流程:

$ mkvirtualenv pip-test
$ pip install nose        # downloaded and installed from PyPi
$ pip install mock        # downloaded and installed from PyPi
$ mkvirtualenv pip-test2
$ pip install nose        # installed from pip's download cache
$ pip install mock        # installed from pip's download cache

问题

由于我没有下载先前已安装在另一个 virtualenv 中的软件包,因此此工作流程可以节省时间和带宽。但是,它不会节省磁盘空间,因为每个包都会安装到每个 virtualenv 中。因此,我想知道:

  • 问题#1是否对此工作流程进行了修改,允许我通过让多个 virtualenv 引用一个 Python 包来节省磁盘空间,而该 Python 包不是安装在我的 Python 2.7 站点包中?

我尝试使用 add2virtualenv 它是 virtualenvwrapper 的一部分。虽然这“将指定的目录添加到当前活动的 virtualenv 的 Python 路径中”,但它不会添加在 virtualenv/bin 目录中找到的任何可执行文件。因此,以下操作将会失败:

$ mkvirtualenv pip-test3
$ add2virtualenv ~/.virtualenvs/pip-test/lib/python2.7/site-packages/nose/
$ nosetests   # Fails since missing ~/.virtualenvs/pip-test3/bin/nosetests
  • 问题 #2 我是否遗漏了 add2virtualenv 工作方式的某些内容?
  • 问题#1 重新表述有没有比 add2virtualenv 更好的方法,允许多个 virtualenv 引用一个安装在我的 Python 2.7 站点包中的 Python 包?
  • 问题 #3 如果有一种方法可以将共享的 Python 包安装到多个 virtualenv 中,那么与将 Python 包单独安装到每个 virtualenv 中相比,是否存在性能损失?
  • 问题 #4 我是否应该放弃节省磁盘空间并坚持当前的工作流程?

Current Python Workflow

I have pip, distribute, virtualenv, and virtualenvwrapper installed into my Python 2.7 site-packages (a framework Python install on Mac OS X). In my ~/.bash_profile I have the line

export PIP_DOWNLOAD_CACHE=$HOME/.pip_download_cache

This gives a workflow as follows:

$ mkvirtualenv pip-test
$ pip install nose        # downloaded and installed from PyPi
$ pip install mock        # downloaded and installed from PyPi
$ mkvirtualenv pip-test2
$ pip install nose        # installed from pip's download cache
$ pip install mock        # installed from pip's download cache

Questions

Since I'm not downloading packages that have been previously installed in another virtualenv, this workflow saves time and bandwidth. However, it doesn't save disk space, since each package will be installed into each virtualenv. Therefore, I'm wondering:

  • Question #1 Is there a modification to this workflow that would allow me to conserve disk space by having multiple virtualenvs reference one Python package that is not installed in my Python 2.7 site-packages?

I've tried using add2virtualenv which is part of virtualenvwrapper. While this "adds the specified directories to the Python path for the currently-active virtualenv," it doesn't add any of the executables found in the virtualenv/bin directory. Therefore, the following will fail:

$ mkvirtualenv pip-test3
$ add2virtualenv ~/.virtualenvs/pip-test/lib/python2.7/site-packages/nose/
$ nosetests   # Fails since missing ~/.virtualenvs/pip-test3/bin/nosetests
  • Question #2 Am I missing something about the way add2virtualenv works?
  • Question #1 Rephrased Is there a better method than add2virtualenv that allows multiple virtualenvs to reference one Python package that is not installed in my Python 2.7 site-packages?
  • Question #3 If there is a method to install a shared Python package into multiple virtualenvs, is there a performance penalty that isn't there compared to installing Python packages separately into each virtualenv?
  • Question #4 Should I just give up on conserving disk space and stick with my current workflow?

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(1

゛时过境迁 2024-09-25 08:52:31

除非您在嵌入式系统上进行开发,否则我发现以这种方式追逐磁盘空间总是适得其反。我花了很长时间才意识到这一点,因为在我长大的时候,一个非常大的硬盘驱动器的大小只有几兆字节,而 RAM 的单位是 K。但是今天,除非你受到非常特殊和不寻常的限制,否则这种好处让你的项目是正交的(你可以删除项目之外任何地方的系统上的任何目录,并且它的Python包仍然存在)似乎总是远远超过磁盘空间的好处,如果你忙于开发,你会无论如何,根据我的经验,从来没有注意到。

所以我想这就是我根据自己的经验提供的教训:您永远不会注意到丢失的磁盘空间,但是如果尝试清理一个地方的目录,您注意到它您的磁盘上破坏了其他地方正在开发的项目。

Unless you are doing development on an embedded system, I find that chasing disk space in this way is always counter-productive. It took me a long time to reach this realization, because I grew up when a very large hard drive was a few megabytes in size, and RAM was measured in K. But today, unless you are under very special and unusual constraints, the benefit of having your projects be orthogonal (you can delete any directories on your system anywhere outside your project, and have its Python packages still there) seems to always far outweigh the disk-space benefit that, if you're busy developing, you'll never — in my experience — even notice anyway.

So I guess that's the lesson I'm offering from my own experience: you'll never notice the disk space you've lost, but you will notice it if trying to clean up a directory in one place on your disk breaks projects under development somewhere else.

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文