[Distutils] Comments on PEP 426

[Donald Stufft]

On Sep 3, 2013, at 5:57 PM, Paul Moore <p.f.moore at gmail.com> wrote:

> On 3 September 2013 22:20, M.-A. Lemburg <mal at egenix.com> wrote:
> IMO, a much better way forward would be to integrate useful setuptools
> changes right back into distutils, so that the monkey patching
> no longer happens and python-dev can officially bless those
> set of changes.
> 
> I'm curious about this possibility. One thing that would ease experimentation in this area, and which has certainly been discussed elsewhere in this thread, would be if there was a clearly defined set of setuptools facilities that are missing from distutils, and which the "modern infrastructure" relies on. Off the top of my head, the following items would definitely be needed:
> 
> 1. An extension to the install command to supply a list of the installed files (the --record feature of setuptools)
> 2. A bdist_wheel command
> 3. Updates to the install (or maybe bdist_egg) commands to emit Metadata 2.0 and dist-info metadata
> 4. An install_scripts command that created script wrappers from metadata (may not be needed if the only supported route to install is via wheels)
> 
> To be honest, these extensions do seem relatively achievable. But I don't know if they are complete - can the advocates of setuptools clarify what facilities of setuptools are needed beyond these (with an indication of where they are used in the build toolchain).
> 
> There are other features of setuptools that I can see would be relevant (for instance, version parsing and requirement checking) but these seem to me to be more in the nature of utility library features than distutils enhancements per se. I'd fully expect that such code could easily be extracted from setuptools (indeed, it may be that all of that code is isolated in pkg_resources already) without needing any of the distutils monkeypatching/extensions.
> 
> It may be that such an approach is reinventing the existing wheel that is setuptools, and indeed it may never go anywhere - but it is an interesting alternative train of thought.
> 
> Paul
> _______________________________________________
> Distutils-SIG maillist  -  Distutils-SIG at python.org
> https://mail.python.org/mailman/listinfo/distutils-sig


The problem is as you start to make this list it starts to get pretty long once you include what required for  different people and at the very best it'll be available only to Python 3.4, most likely python 3.5 which is basically useless to the bulk of packages.

But in the spirit of the conversation i'd also add:

- Dependency Metadata
  - install_requires
  - test_requires
  - setup_requires
    - This needs to reach out and fetch things from PyPI when setup.py is executed so it also needs the ability to install things securely from PyPI
  - Extras
- Console Scripts / Entry Points


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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/distutils-sig/attachments/20130903/55f954de/attachment.html>
-------------- 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/20130903/55f954de/attachment.sig>