[Distutils] Comments on PEP 426

[Nick Coghlan]

On 31 Aug 2013 23:24, "Antoine Pitrou" <solipsis at 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 at python.org
> http://mail.python.org/mailman/listinfo/distutils-sig
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/distutils-sig/attachments/20130901/0ee14041/attachment-0001.html>