[Distutils] Annoucing distribute project

David Cournapeau david at ar.media.kyoto-u.ac.jp
Thu Sep 25 18:39:12 CEST 2008

Tarek Ziadé wrote:
> Well, as long as things are clearly defined in the package, I guess
> FHS compliant
> package could be built with the same source tree.
> We could even install a distribution the FHS way or the self-contained
> way,
> as long as the tool knows what to put where.

Yes, in theory, it is easy: just set which kind of files are put where,
like e.g. autotools (datadir, libdir, etc...). In practice, I am not
sure it will so easy, because distutils is so badly "designed". It
breaks in so many cases, because you never know what is part of the
specification and what is not. Will you break something if you change a
given directory ? You can't know, and testing on one platform is not
enough because distutils authors thought it was a great idea to
dynamically defined most attributes of most classes, with the
consequence that some attributes exist in some cases only, on some
platforms only.

> But that is already the case, a bit:
> For instance we have bdist_rpm, that builds rpms by mapping distutils
> metadata
> to rpm ones,

You can't be general when talking about distutils. All the pain come
from implementation details and undocumented features. I could spend one
hour listing all the sillyness in distutils, none of them being present
in any other build system I have ever encountered.

Again, other people know distutils much better than me and may disagree
with me, or maybe rightfully notice my lack of experience on that
codebase, but from my own work on it - which while not complicated was
not trivial either - I got the conviction that any fundamental change
wrt distutils will be extremely painful to do if not impossible in a
backward compatible way. I was hoping that a distutils replacement would
come for Py3k, actually :)



More information about the Distutils-SIG mailing list