K. Richard Pixley wrote: > Alex Grönholm wrote: >> There is a lack of consensus regarding how exactly they should work. >> If we are having this much trouble deciding how a third party tool >> should work, it is certainly not going to be merged into distutils >> until those issues have been resolved. Distutils is what houses (or >> should) the parts we all agree on. That said, I think that plenty of >> setuptools/distribute functionality should be moved to distutils >> (after the code has been cleaned up and the proper unit tests >> introduced). > I agree there's a lack of consensus. But I dont' believe that > distutils is a strong basis for growth. Distutils may be a reasonable > choice of a build tool, (I'm not sure yet), but it's packaging and > distribution support is minimal to nonexistent.
It is certainly not a good basis as a build tool - it does not handle dependencies for once, and the only thing it really brings is a poor cross-platform implementation to build dynamically loaded libraries, without even a coherent and documented API (you can't introspect something as trivial as compilation flags or where files are built in a cross-platform way, for example). > Most of what I'm talking about here speaks to packaging formats, > distribution processes, and installation processes. And this isn't > new technology. Both debian, rpm, and several other unix technologies > have fine systems in operation right now. Sure, they all have > weaknesses, but they are much better than easy_install. Not if you don't want/can't spend quite some time to know about each supported platform and the tool details. cheers, David _______________________________________________ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig