[Distutils] [Fwd: Re: Annoucing distribute project]

[David Cournapeau]

Greg Ewing wrote:
> I'm not sure the concept of backward compatibility
> makes sense here. The only kind of distutils replacement
> I would be interested in would have a completely different
> API, completely different structure and completely
> different implementation. Anything less would fail to
> fix the problems we want to fix.

I agree with your points (a new system would have a totally different
design), but I believe this does not mean we have to break everything
and force people to start from scratch. For example, in the case of
numscons, I got all the scons features to build C code (automatic
dependencies handling, emitters, configuration, etc...), while keeping
the basic same setup.py files. Being 100 % compatible is not possible,
because distutils is implementation defined; but many projects are not
that complicated, and basic compatibility would be enough, no ? Maybe I
don't realize the complexity (I really don't know anything about
deployment issues for zope, web frameworks like django and co), but do
many projects use all the arcane stuff ?

By adding a new dummy command to distutils, which would hook to a brand
new system (the one you are talking about), we could maybe enable a path
forward ? Things like option handling, distribution: those things cannot
be done in a backward compatible way, because it is broken by design.
But a correct build system, with clean API, separated code and data:
this can be done such as it would be usable from setup.py. Then, later,
we could implement the installation/deployment part, and this part would
not be backward compatible (and we could use something different than
setup.py).

cheers,

David