On Sep 3, 2013, at 5:57 PM, Paul Moore <p.f.mo...@gmail.com> wrote: > On 3 September 2013 22:20, M.-A. Lemburg <m...@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@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
signature.asc
Description: Message signed with OpenPGP using GPGMail
_______________________________________________ Distutils-SIG maillist - Distutils-SIG@python.org https://mail.python.org/mailman/listinfo/distutils-sig
