-
Notifications
You must be signed in to change notification settings - Fork 33
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
RECORD includes no package modules for editable installs #620
Comments
While we can of course change the spec, we should not do so if doing so could result in tools that predate the spec change breaking users' systems... IMO, the only truly "unsurprising" result for We can document the limitations of whatever approach we take, but I think this is just skirting round the real problem here, which is that no-one is able (or willing) to precisely define what an "editable install" should actually contain. |
Having just read the linked bug report, I agree with the conclusion there, that to do this properly needs a decision at the PyPA level. And frankly, that almost certainly needs us to standardise "Editable installs" - which is going to be a long and difficult discussion, I suspect, and quite probably something that people have no appetite for. (Standardising just the API was incredibly divisive, and that deliberately avoided asking "what actually is an editable install" as being too hard a question to tackle!) If we do want to have this discussion, it'll need to happen on Discourse, rather than here, and it'll almost certainly need to end up in the form of a PEP. |
Problem description
In python/cpython#96144, a user expressed their surprise when an editable-installed package had no
importlib.metadata.files()
pertaining to the project. The analysis there concluded that the issue is that the RECORD file for thedist-info
did not include the files the user expected.On one hand, it's infeasible to reflect the files of a package that's editable, as one can always add or delete a file from the package and the metadata will be stale.
On the other hand, it may be practical to reflect the state of the files at the time the package was editable-installed, which would provide users with a better experience and closer feature parity with a standard-installed package.
Should the packaging tools attempt to capture the "files that would be installed" and present those in the RECORD? Or maybe should these files be recorded in a separate metadata file, thereby leaving it up to importlib metadata to determine if/how to expose editable-installed "installed files"?
The text was updated successfully, but these errors were encountered: