[Distutils] backwards compatibility for packaging tools

David Cournapeau david at ar.media.kyoto-u.ac.jp
Sun Sep 28 07:27:01 CEST 2008

zooko wrote:
> When thinking about compatibility, keep in mind the distinction
> between two use cases:
> 1.  You are using a tool (e.g. distutils or setuptools) to package
> your work.  You might consider switching to a new tool, either one
> included in the Python Standard Library or a separately-shipped one,
> to build, package, and distribute your software.
> 2.  You are re-using other people's work that they have packaged and
> distributed.  You might consider switching to a new tool (either
> Python Standard or separate) to re-use their work.
> Backwards compatibility in the first case is not overwhelmingly
> important.  Some people will be willing to entirely rewrite their
> setup.py scripts to use a new tool, other people will be willing to
> use a new tool only if they can keep using their old setup.py scripts,
> and still other people will continue to package and distribute their
> software with Python 2.5 and the distutils that came with it for the
> forseeable future (let's say, for the next 5 years).  We can't prevent
> them from doing that, but also we don't need to persuade them to
> change tools in order to benefit from their work.

I don't think it is accurate. I have no reason to doubt it is true in
your case and many other people's case, but I think you have to be
careful when saying 2 is "obviously" more important than 1. My
impression is that 1 is important for people who invested a lot in
distutils, have a lot of distutils-based extensions. It depends on the
complexity of the setup.py and their build tools around. Again:
numpy.distutils is as big a distutils. For numpy's case, a new well
design would make most of those obsolete, but is it true for any package
which has heavily invested in distutils ?

>From your description, I understand that you care about dependencies,
this kind of things. I know *I* don't care about that for the most part,
and still I would welcome a new distutils. For me, something with a sane
build tool (built around a DAG, not a sequence of commands) is what
matters the most. Something which enables easier packaging by OS vendors

So I would kindly ask to be careful when taking into account what
matters and what not.



More information about the Distutils-SIG mailing list