从 setuptools 迁移到 pip+virtualenv

发布于 2024-10-16 21:59:32 字数 1692 浏览 3 评论 0原文

因此,与 setuptools 相比,pipvirtualenv 听起来很棒。能够卸载就太好了。但我的项目已经在使用 setuptools,那么我该如何迁移?到目前为止我能找到的网站都非常模糊和笼统。因此,在阅读主要网站并尝试之后,这里有一系列问题:

  • 首先,virtualenvpip 现在应该处于可用状态吗?如果不是,请忽略其余的内容,将其视为疯子的胡言乱语。
  • 应该如何安装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 and pip 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 prints src/mplutils.cpp:17: error: ‘vsprintf’ was not declared in this scope.
  • How does either tool interact with setup.py? pip is supposed to replace easy_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 技术交流群。

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

发布评论

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

评论(2

流云如水 2024-10-23 21:59:32

哇,这是一大堆问题。他们中的许多人确实值得提出自己的 SO 问题,并提供更多细节。我会尽力:

首先是virtualenv和pip
应该处于可用状态
现在?

是的,尽管它们不能满足所有人的需求。 Pip 和 virtualenv(以及 Python 包管理中的其他所有内容)远非完美,但它们仍然被广泛使用和依赖。

virtualenv应该如何安装?
我还没准备好相信它是这样
如其他地方所解释的那样令人费解。

您链接的答案很复杂,因为它试图避免对全局 Python 安装进行任何更改,而是将所有内容安装在 ~/.local 中。这有一些优点,但设置起来更复杂。它还安装 virtualenvwrapper,这是一组用于使用 virtualenv 的便捷 bash 脚本,但使用 virtualenv 不是必需的。

如果你使用的是 Ubuntu,aptitude install python-setuptools 后跟 easy_install virtualenv 应该可以让你安装一个有效的 virtualenv,而不会对你的全局 python 环境造成任何损害(除非你也有安装了 Ubuntu virtualenv 软件包,我不推荐它,因为它可能是旧版本)。

是否有一套经过测试的指令
了解如何在中安装 matplotlib
虚拟环境?由于某种原因
它总是想在这里编译它
而不是仅仅安装一个包,
并且总是以失败告终(甚至
占用 250 MB 的 build-dep 之后
磁盘空间)。经过一大堆
它打印的警告
src/mplutils.cpp:17: 错误: 'vsprintf'
未在此范围内声明。

它“总是想要编译”,因为 pip 按照设计,仅从源代码安装,它不安装预编译的二进制文件。这是一个有争议的选择,也可能是 pip 在 Python Web 开发人员中得到最广泛采用的主要原因,他们使用更多纯 Python 包,并且通常在工作编译链为标准的 POSIX 环境中进行开发和部署。

设计选择的原因是,提供预编译的二进制文件在不同平台和构建架构(包括 python 版本、UCS-2 与 UCS-4 python 构建、32 与 64 位...)之间存在组合爆炸问题。大多数情况下,easy_install 在 PyPI 上找到正确的二进制包的方式是有效的,但没有考虑到所有这些因素,并且可能会崩溃。因此 pip 完全避免了这个问题(用你有一个工作编译环境的要求来代替它)。

在许多情况下,需要 C 编译的软件包的发布时间表也较慢,只需为它们安装操作系统软件包也是可以接受的。但这不允许在不同的 virtualenv 中使用它们的不同版本。

我不知道是什么导致你的编译错误,它对我(在 Ubuntu 10.10 上)使用这一系列命令有效:

virtualenv --no-site-packages tmp
. tmp/bin/activate
pip install numpy
pip install -f http://downloads.sourceforge.net/project/matplotlib/matplotlib/matplotlib-1.0.1/matplotlib-1.0.1.tar.gz matplotlib

由于 matplotlib 的 PyPI 上不寻常的下载 URL< /a>.

任一工具如何与
设置.py? pip 应该替换
easy_install,但不清楚
无论是直接上门还是更多
关系复杂。

setup.py 文件是 distutils 的约定, Python 标准库的包管理“解决方案”。 distutils 本身缺少一些关键功能,而 setuptools 是一个广泛使用的工具。 - 使用“拥抱和扩展”distutils 的第三方包来提供一些附加功能。 setuptools 也使用 setup.pyeasy_install 是与 setuptools 捆绑在一起的安装程序。 setuptools 的开发停滞了好几年,distribute 是 setuptools 的一个分支,用于修复一些长期存在的错误。最终,通过将分发合并回 setuptools 解决了分叉问题,并且 setuptools 开发现在再次活跃(有新的维护者)。

distutils2distutils 的一个大部分重写的新版本,它试图融合了 setuptools/distribute 的最佳想法,并且应该成为 Python 标准库的一部分。不幸的是,这一努力失败了,因此目前 setuptools 仍然是 Python 打包的事实上的标准。

pip 取代了 easy_install,但它并没有取代 setuptools;它需要安装工具并在其之上构建。因此它也使用setup.py。

virtualenv仅用于开发
模式,或者用户还应该安装
是吗?

对此没有唯一正确的答案;无论哪种方式都可以使用。最后,这实际上是您的用户的选择,并且您的软件理想情况下应该能够安装在 virtualenv 内部或外部;尽管您可能会选择记录并强调一种方法或另一种方法。这在很大程度上取决于您的用户是谁以及他们可能需要将您的软件安装到什么环境中。

生成的包会是
安装最少
要求(如当前的鸡蛋),
或者它会与源一起安装吗?
所有依赖项的二进制文件以及所有
构建工具,创建千兆字节
虚拟环境中的怪物?

如果需要编译的包是通过 pip 安装的,则需要从源代码编译。这也适用于任何需要编译的依赖项。

这与您是否使用 virtualenv 的问题无关。 easy_install 默认情况下在 virtualenv 中可用,并且在那里工作得很好。它可以安装预编译的二进制 Egg,就像在 virtualenv 之外一样。

用户是否必须修改他们的
$PATH 和 $PYTHONPATH 运行
生成的包(如果安装在)
虚拟环境?

为了使用 virtualenv 中安装的任何内容,您需要使用 virtualenv 的 bin/ 目录中的 python 二进制文件(或安装到 virtualenv 中引用该二进制文件的另一个脚本)。最常见的方法是使用 virtualenv 的 activateactivate.bat 脚本临时修改 shell PATH,以便 virtualenv 的 >bin/ 目录是第一个。对于 virtualenv 来说,修改 PYTHONPATH 通常没有用处或没有必要。

我需要创建一个脚本吗?
virtualenv 的文本字符串,如下所示
过去的日子不好过吗?

不。

#egg=包 URL 有何含义
句法?这不属于
标准 URL,那为什么不是
单独的参数?

“#egg=projectname-version” URL 片段黑客首先是 由 setuptools 和 easy_install 引入。由于 easy_install 从网络上抓取链接来查找给定软件包名称和版本安装的候选发行版,因此该 hack 允许软件包作者在 PyPI 上添加 easy_install 可以理解的链接,即使他们的文件没有使用 easy_install 的标准命名约定。

@rev 包含在 URL 中的什么位置?在
我想结局是这样的,但是
文档对此并不清楚
(“您还可以在
网址”)。

在引用的片段之后的几句话中有一个链接,指向“阅读 需求文件格式 了解其他功能。”@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:

First of all, are virtualenv and pip
supposed to be in a usable state by
now?

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.

How should virtualenv be installed?
I'm not quite ready to believe it's as
convoluted as explained elsewhere.

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 by easy_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).

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 prints
src/mplutils.cpp:17: error: ‘vsprintf’
was not declared in this scope.

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:

virtualenv --no-site-packages tmp
. tmp/bin/activate
pip install numpy
pip install -f http://downloads.sourceforge.net/project/matplotlib/matplotlib/matplotlib-1.0.1/matplotlib-1.0.1.tar.gz matplotlib

The "-f" link is necessary to get the most recent version, due to matplotlib's unusual download URLs on PyPI.

How does either tool interact with
setup.py? pip is supposed to replace
easy_install, but it's not clear
whether it's a drop-in or more
complicated relationship.

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 uses setup.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.

Is virtualenv only for development
mode, or should the users also install
it?

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.

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?

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.

Will the users have to modify their
$PATH and $PYTHONPATH to run the
resulting package if it's installed in
a virtual environment?

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's activate or activate.bat script to temporarily modify the shell PATH so the virtualenv's bin/ directory is first. Modifying PYTHONPATH is not generally useful or necessary with virtualenv.

Do I need to create a script from a
text string for virtualenv like in the
bad old days?

No.

What is with the #egg=Package URL
syntax? That's not part of the
standard URL, so why isn't it a
separate parameter?

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.

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").

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.

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.

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.

疑心病 2024-10-23 21:59:32

我无法回答您所有的问题,但希望以下内容对您有所帮助。

virtualenvpip 都非常有用。许多 Python 开发人员每天都会使用它们。

由于您有一个可用的 easy_install,安装两者的最简单方法如下:

easy_install pip
easy_install virtualenv

一旦您拥有 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 and pip 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:

easy_install pip
easy_install virtualenv

Once you have virtualenv, just type virtualenv yourEnvName and you'll get your new python virtual environment in a directory named yourEnvName.

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 via pip. I haven't found anything that easy_install could do that pip 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 file stable-req.txt based on the existing file devel-req.txt. The only difference will be anything installed not already specified in the existing file will be in the new file.

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