From: Nick Coghlan <ncogh...@gmail.com> > We still need a migration path to modern metadata standards for > everyone using distutils and setuptools - that's the side of things > that caused major problems for both distribute and distutils2.
I've thought about the migration path with distil, which uses a declarative metadata format (superset of PEP-426 as it was a while ago) where the actual metadata is extracted from setup.py files in releases already on PyPI. This works well for simple distributions which don't do anything fancy in setup.py, such as extending build commands to create files on the fly which are then installed etc. In my early testing, distil (which uses no distutils or setuptools code) could install and package distributions which were pure-Python as well as package, build and install ones with C extensions and even Fortran extensions. I haven't done much work on it for a while due to other commitments, but when I had the time to work on it, I noted precious little interest from distutils-sig (yes, I know we're all volunteers, but one person can only do so much). IMO the distil approach comes the closest to a least-work migration path: with distutils2 / packaging that was pulled from 3.3, almost everyone would have to convert their releases to setup.cfg, with limited support for automating this and no support for existing stuff on PyPI, which made it a non-starter. Plus, setup.cfg never supported build-side metadata IIRC, only installation-side. With distil, the metadata for build and installation is *automatically* extracted from setup.py with no work required from packagers e.g. for existing releases, and the extraction only fails if the setup.py code does certain operations which can't be inferred from the actual call to setup() in setup.py (I know that those hard-to-infer operations occur in a lot of releases - but that's the nature of setup.py, where anything goes - I still wanted to see how much progress could be made for the simple cases). The metadata extracted has been useful in other contexts, e.g. Brett Cannon's caniusepython3 uses it to work out package dependencies. With distil, the entire dependency tree is calculated before any package is downloaded at all - something people seem to want - but, it seems, not to the extent of actually doing anything concrete, even to try out code and report problems ... distil isn't perfect and I've said it's more like a proof of concept, but it's quite usable for the "non-fancy" distributions. As long as people are free to put whatever code they want in setup.py, we're not really going to have a simple migration path, because a sizeable number of packagers will carry on doing so, and that'll be hard to convert to declarative metadata automagically (not to mention the situation with existing releases). And as long as there is so much inertia stopping interested parties from trying out new approaches, it seems like the pace of development of better tools will continue to be glacial. Regards, Vinay Sajip _______________________________________________ Distutils-SIG maillist - Distutils-SIG@python.org https://mail.python.org/mailman/listinfo/distutils-sig
