[Distutils] Comments on PEP 426

[Oscar Benjamin]

On 31 August 2013 14: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.

The difference between this

    # setup.py
    if sys.argv[1] == 'install':
        from myproj.build import build
        build()

and something like this

    # setup.cfg
    [install]
    command = "from myproj.build import build; build()"

is that one works now for all relevant Python versions and the other
does not. With the setup.cfg end users cannot simply do 'python
setup.py install' unless they have some additional library that can
understand the setup.cfg. Even if future Python versions gain a new
stdlib module/script for this current versions won't have it.

That is why I agree with Nick that the best thing to do is to
explicitly document what is *currently* required to make things work
and guarantee that it will continue to work for the foreseeable
future. Then alternative better ways to specify the build commands in
future can be considered as hinted in the PEP:
http://www.python.org/dev/peps/pep-0426/#metabuild-system

>> 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).

So is that particular issue a lost cause?

> 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.

It's not just the setup script for a particular project. It's the
particular combination of compilers and setup.py invocations used by
any given user for any given setup.py from each of the thousands of
projects that do anything non-trivial in their setup.py. For example
in the issue I mentioned above the spanner in the works came from PJE
who wanted to use --compiler=mingw32 while surreptitiously placing
Cygwin's gcc on PATH:
http://bugs.python.org/issue12641#msg161514
It's hard for distutils to react to outside changes in e.g. external
compilers because of the need to try and prevent breaking countless
unknown and obscure setups for each end user.

Although in that particular issue I think it's really just a
responsibility thing: the current breakage can be viewed as externally
caused. Fixing it trades a large amount of breakage that is gcc's
fault for a small amount of breakage that would be Python's fault.


Oscar