배포, distutils, setuptools 및 distutils2의 차이점은 무엇입니까?

배포, distutils, setuptools 및 distutils2의 차이점은 무엇입니까?

---

그 상황

오픈 소스 라이브러리를 Python 3으로 포팅하려고합니다. ( SymPy , 궁금한 점이 있으시면 )

따라서 2to3Python 3 용으로 빌드 할 때 자동으로 실행해야합니다. 이렇게하려면 distribute. 따라서 doctest에 따르면 현재 시스템을 포팅해야합니다 distutils.

문제

불행하게도, 나는 확실히 이러한 모듈 -의 차이는 무엇 아니에요 distutils, distribute, setuptools. 문서는 모두 서로의 포크 인 것처럼 보이며 대부분의 상황 (실제로 전부는 아님)에서 호환되도록 의도 된 것처럼 가장 잘 설명되어 있습니다.

질문

누군가 차이점을 설명 할 수 있습니까? 무엇을 사용해야합니까? 가장 현대적인 솔루션은 무엇입니까? (제쳐두고로 포팅에 대한 가이드도 고맙게 생각 Distribute하지만 질문의 범위를 벗어난 것입니다 ...)

---

2017 년 1 월 현재,이 질문에 대한 다른 모든 답변은 최소 2 년이 지난 것입니다. Python 패키징 문제에 대한 조언을 발견하면 게시 날짜를 확인하고 오래된 정보를 신뢰하지 마십시오.

파이썬 포장 사용 설명서는 가치가 읽기입니다. 모든 페이지에는 "마지막 검토"날짜가 표시되어 있으므로 매뉴얼의 최신 성을 확인할 수 있으며 매우 포괄적입니다. Python Software Foundation의 python.org 하위 도메인에서 호스팅된다는 사실은 신뢰를 더합니다. 프로젝트 요약 페이지는 여기에 특히 관련이있다.

도구 요약 :

다음은 2017 년 1 월 Python 패키징 환경을 요약 한 것입니다.

지원되는 도구 :

• Distutils 는 여전히 Python으로 패키징하기위한 표준 도구입니다. 표준 라이브러리 (Python 2 및 Python 3.0 ~ 3.6)에 포함되어 있습니다. 간단한 Python 배포에 유용하지만 기능이 부족합니다. 스크립트 distutils에서 가져올 수있는 Python 패키지를 소개합니다 setup.py.

  • _{공식 문서 | distutilsPython 패키지 사용자 가이드 섹션}

• Setuptools 는 Distutils의 한계를 극복하기 위해 개발되었으며 표준 라이브러리에 포함되어 있지 않습니다. 라는 명령 줄 유틸리티를 도입했습니다 easy_install. 또한 스크립트 로 가져올 수있는 Python 패키지와 배포와 함께 설치된 데이터 파일을 찾기 위해 코드에서 setuptools가져올 수있는 Python 패키지 도 소개했습니다 . 문제 중 하나는 Python 패키지를 원숭이 패치한다는 것 입니다. 그것은 잘 작동합니다 . 정기 출시를 본다.setup.pypkg_resourcesdistutilspip

  • _{공식 문서 | Pypi 페이지 | GitHub 저장소 | setuptoolsPython 패키지 사용자 가이드 섹션}

• scikit-build 는 내부적으로 CMake를 사용하여 컴파일 된 Python 확장을 빌드하는 개선 된 빌드 시스템 생성기입니다. scikit-build는 distutils를 기반으로하지 않기 때문에 실제로 제한 사항이 없습니다. ninja-build가있는 경우 scikit-build는 대안보다 3 배 이상 빠르게 대규모 프로젝트를 컴파일 할 수 있습니다. 그것은 잘 작동합니다 pip. 정기 출시를 본다.

  • _{공식 문서 | Pypi 페이지 | GitHub 저장소}

사용되지 않는 / 포기 된 도구 :

• Distribute 는 Setuptools의 포크였습니다. 동일한 네임 스페이스를 공유하므로 Distribute를 설치 한 경우 import setuptools실제로 Distribute와 함께 배포 된 패키지를 가져옵니다. Distribute가 Setuptools 0.7로 다시 병합 되었으므로 더 이상 Distribute를 사용할 필요가 없습니다. 실제로 Pypi의 버전은 Setuptools를 설치하는 호환성 계층 일뿐입니다.

• Distutils2 는 Distutils, Setuptools 및 Distribute를 최대한 활용하여 Python의 표준 라이브러리에 포함 된 표준 도구가되기위한 시도였습니다. 아이디어는 Distutils2가 이전 Python 버전 용으로 배포되고 Distutils2가 packagingPython 3.3 용 으로 이름이 변경되어 표준 라이브러리에 포함된다는 것이 었습니다. 그러나 이러한 계획은 의도 한대로 진행되지 않았으며 현재 Distutils2는 버려진 프로젝트 입니다. 최신 릴리스는 2012 년 3 월에 있었고 Pypi 홈 페이지가 마침내 업데이트되어 죽음을 반영했습니다.

알파 소프트웨어 :

• Distlib 는 이전 도구 기능의 하위 집합을 구현하는 것을 목표로하는 도구이지만 허용되는 PEP에서 매우 잘 정의 된 기능 만 구현합니다. PyPA (Python Package Authority)의 도구 중 하나이며 언젠가는 Python 표준 라이브러리에 포함될 것입니다. 여전히 알파 소프트웨어로 간주되므로 최종 사용자는주의해야합니다.

  • _{공식 문서 | Pypi 페이지 | Bitbucket 저장소 | distlibPython 패키지 사용자 가이드 섹션}

• 있다 몇 가지 더 많은 도구 (예 : 도시락),하지만이 답변 게시물에 대한 너무 애매한 또는 틈새 시장 또는 이른 또는 미개발이기 때문에 나는 그들을 언급하지 않을 것이다, 그렇지 않으면 그들은 직접 대안 아니에요.

추천:

So in conclusion, out of all these options, I would recommend Setuptools, unless your requirements are very basic and you only need Distutils. Setuptools works very well with Virtualenv and Pip, tools that I highly recommend. Virtualenv and Pip could both be considered official, as they're part of PyPA, and Python 3 now ships ensurepip (which helps you install pip on some systems).

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

As a side-note, I recommend using Virtualenv 1.10 or higher, as it is the first release that recognises the Setuptools/Distribute merger, for both Python 2 and 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:

• The fate of Distutils – Pycon Summit + Packaging Sprint detailed report
• A Quick Diff between Distutils and Distutils2

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

---

NOTE: Answer deprecated, Distribute now obsolete.

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.

---

Many people complained here about the lack of clear community guidance on this issue.

Currently this looks like the best authoritative source on tools recommendations: https://packaging.python.org/en/latest/current.html#tool-recommendations

---

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

---

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.

---

This subject seems to still be in flux. As of 10-31-2013 the "Python Packaging User Guide" Quick Recommendations defines "what toolset is currently recommended". It used to link to "The Future of Python Packaging" which is now, 1/20/2019, 5+ years later, a dead link. :)

참고URL : https://stackoverflow.com/questions/6344076/differences-between-distribute-distutils-setuptools-and-distutils2