WIP prototype pep517-style editable #8154
Conversation
|
is there any plan to support arbitrary namespace package mappings i would really like to be able to map a |
|
@RonnyPfannschmidt That would be up to the backend, I'd expect. Or honestly, a 3rd party tool could be written that built a wheel that exposed anything you like, in any layout you wanted. |
@RonnyPfannschmidt I do have such a use case too, so I'll do some experiments in the coming days/weeks to confirm it's feasible with .pth + import hook. |
|
I already have such a thing prototyped in gumby elf, just not pip integrated |
|
Neat. I don't anticipate any more complexity in what pip exposes than |
src/pip/_internal/req/req_install.py
Outdated
| with open(os.path.join(self.metadata_directory, 'RECORD'), 'w+'): | ||
| pass | ||
|
|
||
| install_unpacked_parsed_wheel( |
There was a problem hiding this comment.
I don't understand the need for this. Why can't the backend just provide a wheel, which we install using the normal install_wheel route? We already have a lot of concepts and we're now adding an "unpacked parsed wheel" that's used to communicate between backend and frontend. That seems like a recipe for confusion...
There was a problem hiding this comment.
This is only the easiest way to copy files into site-packages with pip. Remember the older PEP 376 concept which is a directory with a *.dist-info. That concept also appears in the PEP 517 metadata hook. An unhappy accident that the *.data/ directory would technically work?
If it was a complete wheel it would be a strange one that only worked on this machine and shared the name of the package but not its contents. It would be a hassle to re-implement bdist_wheel in the develop command class, or to create an ephemeral ZipFile and compute RECORD in another build system.
As for pip that function should be broken up even without editable installs. It has a TODO. I've split out the only part that requires a ZipFile.
There was a problem hiding this comment.
Hmm, I notice that this doesn't populate RECORD when it's installed. Thought that was happening before, but maybe not.
| @@ -777,18 +777,49 @@ def install( | |||
|
|
|||
| global_options = global_options if global_options is not None else [] | |||
| if self.editable: | |||
There was a problem hiding this comment.
Somehow I think this should become if self.editable and not self.is_wheel then legacy editable install, else go ahead and install wheel with the regular install_wheel() below, no other change necessary in this function.
There was a problem hiding this comment.
We'll have to decide if this prototype makes sense or if it is just the way pip works. The prototyped approach is to put extra files into the directory into which we have already generated our *.dist-info directory as part of another hook. It's not quite a wheel. It's not necessarily easy for the build system, accustomed to building a regular wheel, to build a completely different kind of wheel. Stub modules in place of the regular contents, no need for compatibility tags, wheel caching, *.data directories, or the RECORD associated with a full wheel.
|
Hello! I am an automated bot and I have noticed that this pull request is not currently able to be merged. If you are able to either merge the |
|
Any update on this? |
|
Another contributor has a different take on the same feature. I'll defer to that pull request. |
|
@dholth Link? I can't find it. |
|
@sbidoul Thanks! |
Closing based on this. |
See https://discuss.python.org/t/third-try-on-editable-installs/3986/22
A new editable hook does an in-place build, populates a directory that will be installed into PLATLIB.