[Distutils] Comments on PEP 426

[Donald Stufft]

On Sep 4, 2013, at 7:13 AM, Paul Moore <p.f.moore at gmail.com> wrote:

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

Wheel -> Doesn't need it
Sdist 2.0 -> MEB system w/ discovery baked into pydist.json
Source Checkout -> ??? Probably some easy to edit file that tells pip which MEB system to use

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

Of course, i'm not against documenting what a setup.py interface should
look like.

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

I think updating distutils is a dead end. Even if we do it in a completely
backwards compatible way it will still only be available in 3.4+ or 3.5+.
We've just recently gotten some confusing advice nullified by the
distribute/setuptools merger so re-adding back in some new confusing
advice seems to be user hostile. "Use setuptools.. unless you're (and
every user who might possibly install your thing) using Python 3.4+
and you're only using this list of features from setuptools we deemed
important, well then you can use distutils.

One of the fundamental problems with setup.py i it's used for both install
and for building. This means that anything that is required to run
the setup.py needs to be available to end users. If you use the proposed
new distutils features (only available in 3.4+) then anyone trying to
install your package on an older version of Python it will not work.


-----------------
Donald Stufft
PGP: 0x6E3CBCE93372DCFA // 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372 DCFA

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://mail.python.org/pipermail/distutils-sig/attachments/20130904/5a9f8755/attachment-0001.sig>