Specification of editable installation

[cjerdonek (Chris Jerdonek)]

@pganssle

In a world where new modules are only added after a re-build, auto-building doesn’t get you the same behavior, because right now even without re-building modules are included in an editable install that are not included in a normal install.

I think this is one of the things we should discuss and make a decision on then, along the lines @uranusjr said (making editable more similar to the regular case). With a new spec, would the goal be to standardize and replicate what we already have, or to add enough to support doing what we think is “right” (even if not done by the existing pip)?

@pganssle

Plus auto-build would change the current behavior pretty dramatically, since it would do things like re-build extension modules and update the metadata, both of which would probably have a bunch of other side-effects.

The idea I had in mind was more of an incremental rebuild (only rebuild what is necessary). @njs mentioned a similar idea in a later comment in the other topic. I’ll quote from part of that comment here:

@njs

Hmm, so here’s a potentially interesting feature for a future version of editable installs. This suggests editable installs are really just a optimization to make reinstalling really fast, and they sacrifice some accuracy to do that. Maybe we can make them a faster or more accurate optimization. For example, what if the backend could provide some extra metadata to hint to the frontend when a rebuild is required ("if any of these files change, do a full reinstall: setup.py , lib/foo.c , …). Then a pipenv-like tool could stay fast when only .py files are updated, but also take on some of the cache consistency tracking that we currently have to do in our heads.