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 _______________________________________________ Distutils-SIG maillist - [email protected] http://mail.python.org/mailman/listinfo/distutils-sig
