Python has a confusing history of tools that can be used to package and describe projects: these include distutils
in the Standard Library, distribute
, distutils2
, and setuptools
(and maybe more). It appears that distribute
and distutils2
were discontinued in favor of setuptools
, which leaves two competing standards.
To my understanding setuptools
offers far more options (e.g. declaring dependencies, tests, etc.) than distutils
, however it is not included in the Python standard library (yet?).
The Python Packaging User Guide[1] recommends now:
Use
setuptools
to define projects and create Source Distributions.
And explains:
Although you can use pure
distutils
for many projects, it does not support defining dependencies on other projects and is missing several convenience utilities for automatically populating package metadata correctly that are provided bysetuptools
. Being outside the standard library, setuptools also offers a more consistent feature set across different versions of Python, and (unlikedistutils
),setuptools
will be updated to produce the upcoming “Metadata 2.0” standard formats on all supported versions.Even for projects that do choose to use
distutils
, when pip installs such projects directly from source (rather than installing from a prebuilt wheel file), it will actually build your project usingsetuptools
instead.
However, looking into various project's setup.py files reveals that this does not seem to be an actual standard. Many packages still use distutils
and those that support setuptools
often mix setuptools
with distutils
e.g. by doing a fallback import:
try:
from setuptools import setup
except ImportError:
from distutils.core import setup
Followed by an attempt to find a way to write a setup that can be installed by both setuptools
and distutils
. This often includes various ways of error-prone dependency checking, since distutils
does not support dependencies in the setup function.
Why are people still making the extra effort to support distutils
- is the fact that setuptools
is not in the standard library the only reason? What are the advantages of distutils
and are there any drawbacks of writing setup.py files that only support setuptools
.
Have a look at this SO question. It explains all the packaging methods very well, and might help answer your question to some extent: Differences between distribute, distutils, setuptools and distutils2?
Distutils is still the standard tool for packaging in Python. It is included in the standard library (Python 2 and Python 3.0 to 3.3). It is useful for simple Python distributions, but lacks features. It introduces the distutils Python package that can be imported in your setup.py script.
Setuptools was developed to overcome Distutils' limitations, and is not included in the standard library. It introduced a command-line utility called easy_install. It also introduced the setuptools Python package that can be imported in your setup.py script, and the pkg_resources Python package that can be imported in your code to locate data files installed with a distribution. One of its gotchas is that it monkey-patches the distutils Python package. It should work well with pip. The latest version was released in July 2013.
So, as you can see setuptools should be preferred to distutils, and I see where your question comes from, however I don't see distutils losing support anytime soon, as, simply put, it is used in many cases with some popular legacy programs. And as you probably know changing these sorts of things in legacy programs can be quite a pain and come with quite a few problems, for example incompatibilities, which would then lead to the developer having to rewrite the source code. So there is that, and also the fact that distutils is a part of the standard python library whereas setuptools is not. So, if you are creating a python program, in this day and age, use setuptools, however keep in mind that without distutils, setuptools would have never existed.