No change in status so far. Currently we have a generally good “big picture” idea of what this should look like:
- backend produces a a pseudo-wheel consisting of wheel metadata plus a mapping between the locations of the files as they should exist in the package and the locations that they exist on disk
- front-end uses whatever mechanism it deems proper to expose those files to Python in such a way that they will update as the files change on disk
We need a proof of concept for that for both setuptools and pip - I firmly believe that any effort at standardizing before we have a proof of concept would be wasted effort, since the standards will likely need to take into account factors that come up during the building and testing phases and if it’s so onerous to build a proof of concept before the standard is constructed, it probably won’t get implemented after the standard is constructed anyway, so the standard is dead in the water anyway.
I am personally super swamped and have less OSS time than ever these days, and what time I do have is going into getting a viable time zone proposal done in time for Python 3.9. I would be happy to have someone else work on the proof of concept for setuptools.
When I did take a crack at it before, the major issue was that distutils (and by extension setuptools) doesn’t have a clean separation between “figure out all the stuff that needs to go into the package” and “put the stuff into the package”, it just sort of assembles the package as it goes. It was a bigger job than I could easily tackle in an afternoon to convert it over to doing it in two steps. If anyone has time to work on this, I can probably fit in some time for advice and likely for review as well. Otherwise I probably won’t have time until at least after PyCon.