Draft PEP: Recording the origin of distributions installed from direct URL references

Structurally, I think the key thing remaining to do is to nominate a long-lived URL under “packaging.python.org/specifications” where this spec will live, and change the references to “amend this PEP” to instead say “write a PEP to amend this specification”.

At a design level, you identified something I had missed with editable installs, which is that they may be specified in more detail at installation time than just “install from this existing local path”.

Relatedly, for local directories that happen to be VCS directories, it may be useful to take a “snapshot” of the VCS state at the time of installation.

However, I think there’s enough additional complexity in trying to track that as part of the “dir_info” struct that it makes sense to defer tackling that to a possible future iteration (e.g. for editable installs, snapshots of discovered VCS info would likely be better created by “pip freeze” itself, whereas for regular installs, the VCS or archive info from the time of installation would be more relevant. For local directories that happen to be VCS directories, it would likely make sense to extract relevant remote repo information).

For now, I think we can safely duck all those questions by saying “The initial iteration of the PEP does not attempt to make environments that include editable installs or installs from local directories reproducible, but it does attempt to make them readily identifiable”.

A quick reality check here - with that qualification, does the PEP (still) address the requirement that originally started this whole discussion (back in this topic)? It’s not obvious to me that it does (because reproducibility seems to be relevant to that use case).

There’s been a lot of water under the bridge since that original post, and it’s worth checking that we’re still solving the problem we started with.

It does. There were two possible approaches to to achieve the original goal (namely make pip freeze work in presence of VCS requirements): 1/ make editable work with pep 517 or 2/ not using editable for that purpose and writing a new spec. Along the way came a better understanding that using editable for the purpose of pip freeze to work correctly with VCS requirements is a distortion of what editable installs are meant for (namely installing a local directory in development mode). So what we have here is a much cleaner and robust approach that does not require editables at all for that purpose.

The latest version of PEP 610 also achieves another, independent goal, which is making the project location of “modern” [1] editable installs identifiable.

[1] By “modern” I mean editable installs that also provide .dist-info metadata, which is the only assumption we are making about them so far, irrespective of the mechanism used to install them.

1 Like

I can add that to the spec. Although, as you noted, discovering the location of the local project directory is sufficient for known use cases of editable installs.