Zooko O'Whielacronx wrote: > On Apr 21, 2009, at 18:54 PM, David Cournapeau wrote: > >> The problem with a new "Distutils2" 100 % compatible with the current >> one is that it is impossible to do without recreating all the things >> which it does wrong, > > I'm sorry, I was unclear. I do not think that it is super important > for a programmer who currently uses setuptools to package their > software to be able to switch to distutils2 to package their software.
Ah, ok, then I indeed partly misunderstood what you said. > I do think that it is super important for a programmer who uses > distutils2 to be able to easily re-use the software written by *other* > people who use setuptools, and vice versa. This means the sdist > format should be interoperable, probably the bdist_egg format should > be interoperable, and the "install_requires" metadata should be > interoperable. Oh, yes, definitely. I would not even imagine designing something where eggs or sdist formats are not *exactly* the same, whether they are produced by distutils, setuptools, distutils2 or whatever. This is why the formats have to be specified, and the code to produce them separated from the rest (e.g. there should be a library to produce an egg from the metadata without using the rest of setuptools, same for sdist, etc...). And this can be done for the current distutils as well anyway. Ideally, the static metadata format should be the same, so that you could really, practically, support both systems 'for free'. At least for simple packages (by simple I mean packages without difficult C code, or more generally specificities which require setup magic, etc...). > It would also be nice if a programmer who is choosing whether to use > setuptools or distutils2 to package their own software could consider > the library of development tools plugins as equally available for > both, instead of thinking "Oh, I could use the new distutils2, which > has a cleaner design and is in Python 2.7, but if I use setuptools > then I can continue to use all these development plugins that already > exist". So if distutils2 can re-use extant setuptools plugins, then > that would be handy. This seems more difficult to do (although I have never thought about this problem to be honest, contrary to the other ones mentioned above - I don't use setuptools that much myself). Many plugins work on the assumption of commands - and if I were to design a new tool, commands would be *the* thing I would like to get rid of (it does not play well with the idea of handling dependencies, for once). cheers, David _______________________________________________ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig
