问题:发行版,distutils,setuptools和distutils2之间的区别?

情况

我正在尝试将开放源代码库移植到Python3。(SymPy,如果有人想知道的话。)

因此,2to3在为Python 3构建时,我需要自动运行。为此,我需要使用distribute。因此,我需要移植当前的系统(根据doctest)是distutils


问题

不幸的是,我不知道什么是这些模块-之间的区别distutilsdistributesetuptools。该文档最好是粗略的,因为它们似乎都是彼此的分支,旨在在大多数情况下兼容(但实际上并非全部)……等等。


问题

有人可以解释差异吗?我应该用什么?什么是最现代的解决方案?(Distribute顺便说一句,我也很感谢有关向移植的一些指南,但这超出了问题的范围……)

The Situation

I’m trying to port an open-source library to Python 3. (SymPy, if anyone is wondering.)

So, I need to run 2to3 automatically when building for Python 3. To do that, I need to use distribute. Therefore, I need to port the current system, which (according to the doctest) is distutils.


The Problem

Unfortunately, I’m not sure what’s the difference between these modules—distutils, distribute, setuptools. The documentation is sketchy as best, as they all seem to be a fork of one another, intended to be compatible in most circumstances (but actually, not all)…and so on, and so forth.


The Question

Could someone explain the differences? What am I supposed to use? What is the most modern solution? (As an aside, I’d also appreciate some guide on porting to Distribute, but that’s a tad beyond the scope of the question…)


回答 0

截至2020年3月,该问题的大多数其他答案已经过时了几年。当您遇到有关Python包装问题的建议时,请记住查看发布日期,并且不要相信过时的信息。

Python包装用户指南》值得一读。每个页面上都显示有“最后更新”日期,因此您可以检查手册的最新性,并且内容非常全面。它托管在Python Software Foundation的python.org的子域中,这本身就增加了可信度。“ 项目摘要”页面在这里尤其重要。

工具摘要:

以下是Python封装环境的摘要:

支持的工具:

弃用/废弃的工具:

  • 是的叉子setuptools。它共享相同的命名空间,因此,如果您安装了Distribute,则import setuptools实际上将导入使用Distribute分发的软件包。Distribute被合并回Setuptools 0.7中,因此您不再需要使用Distribute。实际上,Pypi上的版本只是安装Setuptools的兼容层。

  • 就是把最好的尝试distutilssetuptoolsdistribute成为列入Python的标准库中的标准工具。想法是distutils2将其分发给旧的Python版本,distutils2并将其重命名packaging为Python 3.3,并将其包含在其标准库中。这些计划没有按计划进行,但是目前distutils2是一个废弃的项目。最新版本于2012年3月发布,其Pypi主页最终已更新以反映其死亡。

其他:

如果您有兴趣,还有其他工具,请阅读《 Python打包用户指南》中的“ 项目摘要 ”。我就不一一列举,不重复该网页,并随时回答匹配的问题,这是只有约distributedistutilssetuptoolsdistutils2

建议:

如果这一切对您来说都是新手,并且您不知道从哪里开始,那么,和pipvirtualenv一起很好地结合使用。

如果你正在寻找到virtualenv,你可能有兴趣在这样一个问题:是什么区别venvpyvenvpyenvvirtualenvvirtualenvwrapper,等?。(是的,我知道,我和你一起吟。)

As of March 2020, most of the other answers to this question are several years out-of-date. When you come across advice on Python packaging issues, remember to look at the date of publication, and don’t trust out-of-date information.

The Python Packaging User Guide is worth a read. Every page has a “last updated” date displayed, so you can check the recency of the manual, and it’s quite comprehensive. The fact that it’s hosted on a subdomain of python.org of the Python Software Foundation just adds credence to it. The Project Summaries page is especially relevant here.

Summary of tools:

Here’s a summary of the Python packaging landscape:

Supported tools:

Deprecated/abandoned tools:

  • was a fork of setuptools. It shared the same namespace, so if you had Distribute installed, import setuptools would actually import the package distributed with Distribute. Distribute was merged back into Setuptools 0.7, so you don’t need to use Distribute any more. In fact, the version on Pypi is just a compatibility layer that installs Setuptools.

  • was an attempt to take the best of distutils, setuptools and distribute and become the standard tool included in Python’s standard library. The idea was that distutils2 would be distributed for old Python versions, and that distutils2 would be renamed to packaging for Python 3.3, which would include it in its standard library. These plans did not go as intended, however, and currently, distutils2 is an abandoned project. The latest release was in March 2012, and its Pypi home page has finally been updated to reflect its death.

Others:

There are other tools, if you are interested, read Project Summaries in the Python Packaging User Guide. I won’t list them all, to not repeat that page, and to keep the answer matching the question, which was only about distribute, distutils, setuptools and distutils2.

Recommendation:

If all of this is new to you, and you don’t know where to start, , along with pip and virtualenv, which all work very well together.

If you’re looking into virtualenv, you might be interested in this question: What is the difference between venv, pyvenv, pyenv, virtualenv, virtualenvwrapper, etc?. (Yes, I know, I groan with you.)


回答 1

我是distutils维护者和distutils2 / packaging贡献者。我在ConFoo 2011上谈论了Python封装,如今,我正在编写它的扩展版本。它尚未发布,因此以下是一些有助于定义内容的摘录。

  • Distutils是用于包装的标准工具。它可以满足简单的需求,但功能有限,扩展范围也不小。

  • Setuptools是一个旨在填补缺少的distutils功能并探索新方向的项目。在某些子社区中,这是事实上的标准。它使用了Python核心开发人员不喜欢的Monkey补丁和魔术。

  • Distribute是Setuptools的一个分支,由开发人员启动,觉得它的开发速度太慢并且无法对其进行开发。当distutils2由同一组启动时,其开发速度大大减慢。2013年8月更新:分发重新合并到setuptools中并停止使用。

  • Distutils2是一个新的distutils库,它是distutils代码库的一个分支,从安装工具(其中一些已在PEP中进行了详细讨论)中汲取了好主意,并且是受pip启发的基本安装程序。 用来导入Distutils2的实际名称packaging在Python 3.3+标准库中,或者distutils2在2.4+和3.1-3.2中。(将很快提供一个反向端口。) Distutils2并未发布Python 3.3版本,因此被搁置了。

更多信息:

我希望很快完成我的指南,它将包含有关每个图书馆的优缺点的更多信息以及过渡指南。

I’m a distutils maintainer and distutils2/packaging contributor. I did a talk about Python packaging at ConFoo 2011 and these days I’m writing an extended version of it. It’s not published yet, so here are excerpts that should help define things.

  • Distutils is the standard tool used for packaging. It works rather well for simple needs, but is limited and not trivial to extend.

  • Setuptools is a project born from the desire to fill missing distutils functionality and explore new directions. In some subcommunities, it’s a de facto standard. It uses monkey-patching and magic that is frowned upon by Python core developers.

  • Distribute is a fork of Setuptools that was started by developers feeling that its development pace was too slow and that it was not possible to evolve it. Its development was considerably slowed when distutils2 was started by the same group. 2013-August update: distribute is merged back into setuptools and discontinued.

  • Distutils2 is a new distutils library, started as a fork of the distutils codebase, with good ideas taken from setup tools (of which some were thoroughly discussed in PEPs), and a basic installer inspired by pip. The actual name you use to import Distutils2 is packaging in the Python 3.3+ standard library, or distutils2 in 2.4+ and 3.1–3.2. (A backport will be available soon.) Distutils2 did not make the Python 3.3 release, and it was put on hold.

More info:

I hope to finish my guide soon, it will contain more info about each library’s strong and weak points and a transition guide.


回答 2

注意:已弃用答案,现在分发已过时。自Python打包机构成立以来,该答案不再有效,并且已经做了很多工作来清理此问题。


是的,您知道了。:-o我认为目前首选的软件包是Distribute,它是setuptools的一个分支,是distutils(原始打包系统)的扩展。Setuptools并未得到维护,因此已被分叉并重命名,但是在安装时,它使用setuptools的软件包名称!我认为大多数Python开发人员现在都使用Distribute,并且可以肯定地说我确实这样做。

NOTE: Answer deprecated, Distribute now obsolete. This answer is no longer valid since the Python Packaging Authority was formed and has done a lot of work cleaning this up.


Yep, you got it. :-o I think at this time the preferred package is Distribute, which is a fork of setuptools, which are an extension of distutils (the original packaging system). Setuptools was not being maintained so is was forked and renamed, however when installed it uses the package name of setuptools! I think most Python developers now use Distribute, and I can say for sure that I do.


回答 3

我意识到我已经回答了您的第二个问题,但没有解决您原始问题中的毫无疑问的假设:

我正在尝试将开放源代码库(SymPy,如果有人想知道)移植到Python3。为此,在构建Python 3时,我需要自动运行2to3。

可能不是需要。其他策略请参见http://docs.python.org/dev/howto/pyporting

为此,我需要使用分配,

可能 :) distutils以不同的分发方式支持代码(不是docstrings)的构建时2to3转换:http : //docs.python.org/dev/howto/pyporting#during-installation

I realize that I have replied to your secondary question without addressing unquestioned assumptions in your original problem:

I’m trying to port an open-source library (SymPy, if anyone is wondering) to Python 3. To do this, I need to run 2to3 automatically when building for Python 3.

You may, not need. Other strategies are described at http://docs.python.org/dev/howto/pyporting

To do that, I need to use distribute,

You may :) distutils supports build-time 2to3 conversion for code (not docstrings), in a different manner that distribute’s: http://docs.python.org/dev/howto/pyporting#during-installation


回答 4

2014年底更新了这个问题,幸运的是,Continuum的“ conda ”软件包管理器已大大消除了Python的包装混乱。

特别是,conda可以快速创建conda“ 环境 ”。您可以使用不同版本的Python配置您的环境。例如:

conda create -n py34 python=3.4 anaconda

conda create -n py26 python=2.6 anaconda

将使用不同版本的Python创建两个(“ py34”或“ py26”)Python环境。

之后,您可以使用以下特定版本的Python调用环境:

source activate <env name>

在必须处理不同版本的Python的情况下,此功能似乎特别有用。

而且,conda具有以下功能:

  • 不可知的Python
  • 跨平台
  • 无需管理员权限
  • 智能依赖性管理(通过SAT求解器)
  • 很好地处理了您可能必须链接的C,Fortran和系统级库

如果您身处科学计算领域,那么最后一点尤其重要。

Updating this question in late 2014 where fortunately the Python packaging chaos has been greatly cleaned up by Continuum’s “conda” package manager.

In particular, conda quickly enables the creation of conda “environments“. You can configure your environments with different versions of Python. For example:

conda create -n py34 python=3.4 anaconda

conda create -n py26 python=2.6 anaconda

will create two (“py34” or “py26”) Python environments with different versions of Python.

Afterwards you can invoke the environment with the specific version of Python with:

source activate <env name>

This feature seems especially useful in your case where you are having to deal with different version of Python.

Moreover, conda has the following features:

  • Python agnostic
  • Cross platform
  • No admin privileges required
  • Smart dependency management (by way of a SAT solver)
  • Nicely deals with C, Fortran and system level libraries that you may have to link against

That last point is especially important if you are in the scientific computing arena.


声明:本站所有文章,如无特殊说明或标注,均为本站原创发布。任何个人或组织,在未征得本站同意时,禁止复制、盗用、采集、发布本站内容到任何网站、书籍等各类媒体平台。如若本站内容侵犯了原著者的合法权益,可联系我们进行处理。