[Distutils] Comments on PEP 426

[Paul Moore]

On 4 September 2013 11:30, Donald Stufft <donald at stufft.io> wrote:
> On Sep 4, 2013, at 6:21 AM, "M.-A. Lemburg" <mal at egenix.com> wrote:
>
>> I quite like the idea of using setup.py as high level
>> interface to a package for installers to use, since that
>> avoids having to dig into the details built into the
>> setup.py code (and whether it uses setuptools, bento,
>> custom code, etc.).
>
> I like it as a temporary solution that is backwards compatible with the old
> tooling but I don't think it should be the interface going into the future.

I don't think anyone has even begun to discuss what such an "interface
for the future" should be. In principle that would be nice, but on a
pure practicality point of view documenting current practice makes a
lot of sense.

It also offers the option of having a spec that backward compatibility
adapters could use to allow current tools to work with the "interface
for the future" when that arrives.

> All of this completely skirts the fact that any change to distutils would only
> be available in 3.4+ or 3.5+ which makes it's value practically zero. It's
> not like other modules in the library where you can reasonably expect
> someone to have a backport installed if you need to use the new features.
> Setuptools has already gone through the long process of getting everyone
> to get it installed, why would we want to go through that again for a system
> that should eventually be deprecated entirely?

I think you misunderstand at least what I am suggesting. You can,
right now, write code in your setup.py that provides a bdist_wheel
command, using pure distutils. (That's the "cmdclass" interface that
MAL has mentioned). That would work on any version of Python with
distutils, no matter how old. It's quite a lot of code, so you may
want to split it out into a separate module, and you may then want to
make that module available independently for other projects to use,
but that's not actually relevant. It's essentially what setuptools
already does, the only real difference is that setuptools actually
modifies the extensibility methods of distutils rather than just using
them.

There may be some more complex areas where actual changes to distutils
are required. That's precisely what I'd like to see established - if
we knew what that "minimal API" was that setup.py had to provide, we'd
be able to experiment to find out if we could provide it without
distutils changes or not.

[BTW, this is *precisely* the sort of debate that is non-productive if
the mandate is to use setuptools. It's why I keep asking for clarity
on the status of setuptools - do projects have the option of trying
this sort of thing out and therefore asking for explanations of what
they need to provide to support packaging tools, or is that option
explicitly rejected and those projects need to import setup from
setuptools and stop trying to implement their own version? Mandating
setuptools would cut off the drain on time that is threads like this -
at the cost of potentially alienating those people who still want to
explore such options.]

Paul