Yes of course. The backend will want to use a library.
Say build(… a few facts about the package) and be ready to go.
I’ve updated the hook in pip and setuptools. It makes pip simpler which I think is great. Don’t worry about the .pth file, now moved into setuptools’ part of the hook.
The naming of the parameters is a little awkward. I have passed the same metadata_directory from prepare_metadata_for_build_wheel. It is like the root of a wheel. It contains the *.dist-info directory.
It is easier for setuptools to let the other hook take care of *.dist-info which is always accomplished by bdist_wheel converting an .egg-info directory. (Any number of setuptools metadata plugins write to egg-info during its build). We already caled the metadata hook to find dependencies before installing our editable distribution.
I tested this against pip’s test project python -m pip install -e tests/data/packages/pep517_setup_and_pyproject/
Thanks to @sbidoul we have an additional POC that requires a .whl instead of my directory-copied-into-$PLATLIB. It even says it’s “somewhat useable”
I’d like to have the option to do relative paths, which is as simple as passing a target directory or an install scheme into the hook.
I’m wary of including all wheel features. Does this need to support installing into all the *.data/ categories, choose purelib vs. platlib, include platform tags, be able to be cached or sent over a network. But I could live with it.
It’s easy enough to throw in RECORD and zip up the directory if that’s the hook we land on. I think I’d wind up using a dedicated “zip up a wheel” implementation just for editable wheels in enscons. In setuptools there would be a chance that we’d re-use wheel’s WheelFile but no chance we’d re-use bdist_wheel to create the special wheel *
* except that bdist_wheel was involved in creating the .dist-info directory made available to the editable hook
i hope i find some time to try this with gumby elf (it does generate wheels that match exactly whats needed (all data is left in the checkout, only shim files are in record)
The idea is that the build_wheel_for_editable wheel should contain the regular metadata and proxy modules for each top-level name. When the proxies are imported they replace themselves with the actual module and something that allows the rest of the module to be imported. https://github.com/pfmoore/editables/blob/master/src/editables/__init__.py is Paul’s submission for building those proxies.
I’ve just published my editables library. PyPI page and github. It’s published under my own name for now. If it ends up being accepted as the reference implementation, we can move it under the PyPA banner.
I’d love to see this gets some proper field testing (and of course, contributions welcome if people find limitations or can think of improvements
