Next steps for editable / develop proof of concept

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” :cowboy_hat_face:

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

Thanks @sbidoul!

2 Likes

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)

thanks @sbidoul

1 Like

I updated my frontend (pip) POC with a scheme argument to build_wheel_for_editable, so interested people can experiment with that too.

@takluyver you may want to try my build_wheel_for_editable POC with this pip branch.

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.

…which I fully intend to expand into a properly reusable library. But I’m super snowed under right now, so I haven’t had time.

My offer to help with moving this still stands if we can agree on those best practices :sweat_smile:

1 Like

IMO we still need prototypes. Then we can choose the best one.