从 setuptools 迁移到 pip+virtualenv
因此,与 setuptools
相比,pip
和 virtualenv
听起来很棒。能够卸载就太好了。但我的项目已经在使用 setuptools
,那么我该如何迁移?到目前为止我能找到的网站都非常模糊和笼统。因此,在阅读主要网站并尝试之后,这里有一系列问题:
- 首先,
virtualenv
和pip
现在应该处于可用状态吗?如果不是,请忽略其余的内容,将其视为疯子的胡言乱语。 - 应该如何安装
virtualenv
?我还没有准备好相信它像 在别处解释。 - 是否有一组关于如何安装 matplotlib 的经过测试的说明在虚拟环境中?由于某种原因,它总是想在这里编译它,而不是仅仅安装一个包,并且它总是以失败告终(即使在
build-dep
占用了 250 MB磁盘空间)。经过一大堆警告后,它会打印src/mplutils.cpp:17: error: 'vsprintf' was notelasted in thisscope
。 - 这两个工具如何与 setup.py 交互?
pip
应该取代easy_install
,但尚不清楚它是直接插入还是更复杂的关系。 - virtualenv仅用于开发模式,还是用户也应该安装它?
- 生成的包是否会按照最低要求安装(如当前的 Egg),或者是否会按照源代码安装?所有依赖项的二进制文件加上所有构建工具,在虚拟环境中创建一个千兆字节的怪物?
- 如果结果包安装在虚拟环境中,用户是否必须修改其
$PATH
和$PYTHONPATH
才能运行生成的包? - 我是否需要从文本字符串创建 脚本 对于
virtualenv
就像过去糟糕的日子一样? #egg=Package
URL 语法有什么用?这不是标准 URL 的一部分,那么为什么它不是一个单独的参数呢?- @rev 包含在 URL 中的什么位置?最后我想,但文档对此并不清楚(“您还可以在 URL 中包含 @rev”)。
- 使用现有的需求文件作为新文件的模板应该理解什么“?这可能意味着很多事情。
So pip
and virtualenv
sound wonderful compared to setuptools
. Being able to uninstall would be great. But my project is already using setuptools
, so how do I migrate? The web sites I've been able to find so far are very vague and general. So here's an anthology of questions after reading the main web sites and trying stuff out:
- First of all, are
virtualenv
andpip
supposed to be in a usable state by now? If not, please disregard the rest as the ravings of a madman. - How should
virtualenv
be installed? I'm not quite ready to believe it's as convoluted as explained elsewhere. - Is there a set of tested instructions for how to install matplotlib in a virtual environment? For some reason it always wants to compile it here instead of just installing a package, and it always ends in failure (even after
build-dep
which took up 250 MB of disk space). After a whole bunch of warnings it printssrc/mplutils.cpp:17: error: ‘vsprintf’ was not declared in this scope
. - How does either tool interact with
setup.py
?pip
is supposed to replaceeasy_install
, but it's not clear whether it's a drop-in or more complicated relationship. - Is virtualenv only for development mode, or should the users also install it?
- Will the resulting package be installed with the minimum requirements (like the current egg), or will it be installed with sources & binaries for all dependencies plus all the build tools, creating a gigabyte monster in the virtual environment?
- Will the users have to modify their
$PATH
and$PYTHONPATH
to run the resulting package if it's installed in a virtual environment? - Do I need to create a script from a text string for
virtualenv
like in the bad old days? - What is with the
#egg=Package
URL syntax? That's not part of the standard URL, so why isn't it a separate parameter? - Where is @rev included in the URL? At the end I suppose, but the documentation is not clear about this ("You can also include @rev in the URL").
- What is supposed to be understood by using an existing requirements file as "as a sort of template for the new file"? This could mean any number of things.
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(2)
哇,这是一大堆问题。他们中的许多人确实值得提出自己的 SO 问题,并提供更多细节。我会尽力:
是的,尽管它们不能满足所有人的需求。 Pip 和 virtualenv(以及 Python 包管理中的其他所有内容)远非完美,但它们仍然被广泛使用和依赖。
您链接的答案很复杂,因为它试图避免对全局 Python 安装进行任何更改,而是将所有内容安装在
~/.local
中。这有一些优点,但设置起来更复杂。它还安装 virtualenvwrapper,这是一组用于使用 virtualenv 的便捷 bash 脚本,但使用 virtualenv 不是必需的。如果你使用的是 Ubuntu,
aptitude install python-setuptools
后跟easy_install virtualenv
应该可以让你安装一个有效的 virtualenv,而不会对你的全局 python 环境造成任何损害(除非你也有安装了 Ubuntu virtualenv 软件包,我不推荐它,因为它可能是旧版本)。它“总是想要编译”,因为 pip 按照设计,仅从源代码安装,它不安装预编译的二进制文件。这是一个有争议的选择,也可能是 pip 在 Python Web 开发人员中得到最广泛采用的主要原因,他们使用更多纯 Python 包,并且通常在工作编译链为标准的 POSIX 环境中进行开发和部署。
设计选择的原因是,提供预编译的二进制文件在不同平台和构建架构(包括 python 版本、UCS-2 与 UCS-4 python 构建、32 与 64 位...)之间存在组合爆炸问题。大多数情况下,easy_install 在 PyPI 上找到正确的二进制包的方式是有效的,但没有考虑到所有这些因素,并且可能会崩溃。因此 pip 完全避免了这个问题(用你有一个工作编译环境的要求来代替它)。
在许多情况下,需要 C 编译的软件包的发布时间表也较慢,只需为它们安装操作系统软件包也是可以接受的。但这不允许在不同的 virtualenv 中使用它们的不同版本。
我不知道是什么导致你的编译错误,它对我(在 Ubuntu 10.10 上)使用这一系列命令有效:
由于 matplotlib 的 PyPI 上不寻常的下载 URL< /a>.
setup.py
文件是 distutils 的约定, Python 标准库的包管理“解决方案”。distutils
本身缺少一些关键功能,而 setuptools 是一个广泛使用的工具。 - 使用“拥抱和扩展”distutils 的第三方包来提供一些附加功能。setuptools
也使用setup.py
。easy_install
是与 setuptools 捆绑在一起的安装程序。 setuptools 的开发停滞了好几年,distribute 是 setuptools 的一个分支,用于修复一些长期存在的错误。最终,通过将分发合并回 setuptools 解决了分叉问题,并且 setuptools 开发现在再次活跃(有新的维护者)。distutils2 是
distutils
的一个大部分重写的新版本,它试图融合了 setuptools/distribute 的最佳想法,并且应该成为 Python 标准库的一部分。不幸的是,这一努力失败了,因此目前 setuptools 仍然是 Python 打包的事实上的标准。pip 取代了 easy_install,但它并没有取代 setuptools;它需要安装工具并在其之上构建。因此它也使用setup.py。
对此没有唯一正确的答案;无论哪种方式都可以使用。最后,这实际上是您的用户的选择,并且您的软件理想情况下应该能够安装在 virtualenv 内部或外部;尽管您可能会选择记录并强调一种方法或另一种方法。这在很大程度上取决于您的用户是谁以及他们可能需要将您的软件安装到什么环境中。
如果需要编译的包是通过 pip 安装的,则需要从源代码编译。这也适用于任何需要编译的依赖项。
这与您是否使用 virtualenv 的问题无关。
easy_install
默认情况下在 virtualenv 中可用,并且在那里工作得很好。它可以安装预编译的二进制 Egg,就像在 virtualenv 之外一样。为了使用 virtualenv 中安装的任何内容,您需要使用 virtualenv 的
bin/
目录中的 python 二进制文件(或安装到 virtualenv 中引用该二进制文件的另一个脚本)。最常见的方法是使用 virtualenv 的activate
或activate.bat
脚本临时修改 shellPATH
,以便 virtualenv 的>bin/
目录是第一个。对于 virtualenv 来说,修改PYTHONPATH
通常没有用处或没有必要。不。
“#egg=projectname-version” URL 片段黑客首先是 由 setuptools 和 easy_install 引入。由于 easy_install 从网络上抓取链接来查找给定软件包名称和版本安装的候选发行版,因此该 hack 允许软件包作者在 PyPI 上添加 easy_install 可以理解的链接,即使他们的文件没有使用 easy_install 的标准命名约定。
在引用的片段之后的几句话中有一个链接,指向“阅读 需求文件格式 了解其他功能。”
@rev
功能在那里有完整的记录和演示。下一句话说“它将保持 devel-req.txt 中列出的包按顺序排列并保留注释。”我不确定什么是更好的简洁描述。
Wow, that's quite a set of questions. Many of them would really deserve their own SO question with more details. I'll do my best:
Yes, although they don't serve everyone's needs. Pip and virtualenv (along with everything else in Python package management) are far from perfect, but they are widely used and depended upon nonetheless.
The answer you link is complex because it is trying to avoid making any changes at all to your global Python installation and install everything in
~/.local
instead. This has some advantages, but is more complex to setup. It's also installing virtualenvwrapper, which is a set of convenience bash scripts for working with virtualenv, but is not necessary for using virtualenv.If you are on Ubuntu,
aptitude install python-setuptools
followed byeasy_install virtualenv
should get you a working virtualenv installation without doing any damage to your global python environment (unless you also had the Ubuntu virtualenv package installed, which I don't recommend as it will likely be an old version).It "always wants to compile" because pip, by design, installs only from source, it doesn't install pre-compiled binaries. This is a controversial choice, and is probably the primary reason why pip has seen widest adoption among Python web developers, who use more pure-Python packages and commonly develop and deploy in POSIX environments where a working compilation chain is standard.
The reason for the design choice is that providing precompiled binaries has a combinatorial explosion problem with different platforms and build architectures (including python version, UCS-2 vs UCS-4 python builds, 32 vs 64-bit...). The way easy_install finds the right binary package on PyPI sort of works, most of the time, but doesn't account for all these factors and can break. So pip just avoids that issue altogether (replacing it with a requirement that you have a working compilation environment).
In many cases, packages that require C compilation also have a slower-moving release schedule and it's acceptable to simply install OS packages for them instead. This doesn't allow working with different versions of them in different virtualenvs, though.
I don't know what's causing your compilation error, it works for me (on Ubuntu 10.10) with this series of commands:
The "-f" link is necessary to get the most recent version, due to matplotlib's unusual download URLs on PyPI.
The
setup.py
file is a convention of distutils, the Python standard library's package management "solution."distutils
alone is missing some key features, and setuptools is a widely-used third-party package that "embraces and extends" distutils to provide some additional features.setuptools
also usessetup.py
.easy_install
is the installer bundled with setuptools. Setuptools development stalled for several years, and distribute was a fork of setuptools to fix some longstanding bugs. Eventually the fork was resolved with a merge of distribute back into setuptools, and setuptools development is now active again (with a new maintainer).distutils2 was a mostly-rewritten new version of
distutils
that attempted to incorporate the best ideas from setuptools/distribute, and was supposed to become part of the Python standard library. Unfortunately this effort failed, so for the time being setuptools remains the de facto standard for Python packaging.Pip replaces easy_install, but it does not replace setuptools; it requires setuptools and builds on top of it. Thus it also uses
setup.py
.There's no single right answer to that; it can be used either way. In the end it's really your user's choice, and your software ideally should be able to be installed inside or out of a virtualenv; though you might choose to document and emphasize one approach or the other. It depends very much on who your users are and what environments they are likely to need to install your software into.
If a package that requires compilation is installed via pip, it will need to be compiled from source. That also applies to any dependencies that require compilation.
This is unrelated to the question of whether you use a virtualenv.
easy_install
is available by default in a virtualenv and works just fine there. It can install pre-compiled binary eggs, just like it does outside of a virtualenv.In order to use anything installed in a virtualenv, you need to use the python binary in the virtualenv's
bin/
directory (or another script installed into the virtualenv that references this binary). The most common way to do this is to use the virtualenv'sactivate
oractivate.bat
script to temporarily modify the shellPATH
so the virtualenv'sbin/
directory is first. ModifyingPYTHONPATH
is not generally useful or necessary with virtualenv.No.
The "#egg=projectname-version" URL fragment hack was first introduced by setuptools and easy_install. Since easy_install scrapes links from the web to find candidate distributions to install for a given package name and version, this hack allowed package authors to add links on PyPI that easy_install could understand, even if they didn't use easy_install's standard naming conventions for their files.
A couple sentences after that quoted fragment there is a link to "read the requirements file format to learn about other features." The
@rev
feature is fully documented and demonstrated there.The very next sentence says "it will keep the packages listed in devel-req.txt in order and preserve comments." I'm not sure what would be a better concise description.
我无法回答您所有的问题,但希望以下内容对您有所帮助。
virtualenv
和pip
都非常有用。许多 Python 开发人员每天都会使用它们。由于您有一个可用的 easy_install,安装两者的最简单方法如下:
一旦您拥有 virtualenv,只需键入
virtualenv yourEnvName
,您就会在名为的目录中获得新的 python 虚拟环境。你的环境名称
。从那里,它就像
source yourEnvName/bin/activate
一样简单,虚拟 python 解释器将成为您的活动。我对 matplotlib 一无所知,但是遵循安装交互应该可以正常工作,除非存在奇怪的硬编码路径问题。如果您可以通过
easy_install
安装某些东西,通常可以通过pip
安装它。我还没有发现任何easy_install
可以做而pip
做不到的事情。我不指望用户能够安装
virtualenv
(这取决于您的用户是谁)。从技术上讲,在大多数情况下,虚拟 Python 解释器可以被视为真实的解释器。它的主要用途不是弄乱真正的解释器的站点包,并且如果您有两个库/应用程序需要同一库的不同且不兼容的版本。如果您或用户在 virtualenv 中安装了某些内容,则该内容在其他 virtualenv 或系统 Python 解释器中将不可用。您需要使用
source /path/to/yourvirtualenv/bin/activate
命令切换到安装该库的虚拟环境。他们所说的“作为新文件的一种模板”的意思是 pip freeze -r devel-req.txt > stable-req.txt 命令将基于现有文件
devel-req.txt
创建一个新文件stable-req.txt
。唯一的区别是现有文件中尚未指定的任何已安装内容都将在新文件中。I can't answer all your questions, but hopefully the following helps.
Both
virtualenv
andpip
are very usable. Many Python devs use these everyday.Since you have a working easy_install, the easiest way to install both is the following:
Once you have virtualenv, just type
virtualenv yourEnvName
and you'll get your new python virtual environment in a directory namedyourEnvName
.From there, it's as easy as
source yourEnvName/bin/activate
and the virtual python interpreter will be your active. I know nothing about matplotlib, but following the installation interactions should work out ok unless there are weird hard-coded path issues.If you can install something via
easy_install
you can usually install it viapip
. I haven't found anything thateasy_install
could do thatpip
couldn't.I wouldn't count on users being able to install
virtualenv
(it depends on who your users are). Technically, a virtual python interpreter can be treated as a real one for most cases. It's main use is not cluttering up the real interpreter's site-packages and if you have two libraries/apps that require different and incompatible versions of the same library.If you or a user install something in a virtualenv, it won't be available in other virtualenvs or the system Python interpreter. You'll need to use
source /path/to/yourvirtualenv/bin/activate
command to switch to a virtual environment you installed the library on.What they mean by "as a sort of template for the new file" is that the
pip freeze -r devel-req.txt > stable-req.txt
command will create a new filestable-req.txt
based on the existing filedevel-req.txt
. The only difference will be anything installed not already specified in the existing file will be in the new file.