On 31 Aug 2013 23:24, "Antoine Pitrou" <solip...@pitrou.net> wrote: > > Oscar Benjamin <oscar.j.benjamin <at> gmail.com> writes: > > > > It will always be possible to ship a setup.py script that can > > build/install from an sdist or VCS checkout. The issue is about how to > > produce an sdist with a setup.py that is guaranteed to work with past, > > current, and future versions of distutils/pip/setuptools/some other > > installer so that you can upload it to PyPI and people can run 'pip > > install myproj'. It shouldn't be necessary for the package author to > > use distutils/setuptools in their setup.py just because the user wants > > to install with pip/setuptools or vice-versa. > > Agreed... But then, deprecating setup.py in favour of setup.cfg is a > more promising path for cross-tool compatibility, than trying to promote > one tool over another. > > > Distutils is tied down with backward compatibility because of the > > number of projects that would break if it changed. Even obvious > > breakage like http://bugs.python.org/issue12641 goes unfixed for years > > because of worries that fixing it for 10000 users would break some > > obscure setup for 100 users (no matter how broken that other setup > > might otherwise be). > > I tend to disagree. Such bugs are not fixed, not because they shouldn't / > can't be fixed, but because distutils isn't really competently maintained > (or not maintained at all, actually; Éric sometimes replies on bug entries > but he doesn't commit anything these days). > > The idea that "distutils shouldn't change" was more of a widely-promoted > propaganda item than a rational decision, IMO. Most setup scripts wouldn't > suffer from distutils changes or improvements; the few that *may* suffer > belong to large projects which probably have other items to solve when a > new Python comes out, anyway.
Blessing build tools implicitly replacing distutils with setuptools is indeed an *awful* hack, but it is also the only way I see to break the chicken-and-egg adoption problem for new metadata standards. It *must* be possible for build tools to get next generation (or even current generation) metadata out of existing vanilla distutils projects, even on older versions of Python. They can't do that if they're required to use distutils exactly as it is shipped in the standard library rather than swapping in something like setuptools (or a currently still hypothetical simpler alternative that just emits the new formats without adding other setuptools features). By blessing such substitutions, most projects will implicitly support the new standards without needing to migrate to a new build system. Even the current bento issue mentioned in this thread appears to be Windows specific. Replacing or monkey-patching distutils is definitely a terrible hack, but it's also a hack that pip already uses, and one that should allow metadata 2.0 to avoid the near total lack of adoption that afflicted metadata 1.2. Cheers, Nick. > > Regards > > Antoine. > > > _______________________________________________ > Distutils-SIG maillist - Distutils-SIG@python.org > http://mail.python.org/mailman/listinfo/distutils-sig
_______________________________________________ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig