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

Packaging
61

I’m slightly worried that the direct URL record isn’t used much except in pip freeze, where the output is quite forgiving. I kind of want to see something that uses the direct URL info in its structured form to prove the current format is useful without backward incompatible changes. Specifically I want to know whether the current format has enough to support direct URL upgrade strategy.

62

Not an unreasonable suggestion, but there’s no ETA on that change, and I think the normal practice is for features to be provisional for a set period of time, rather than based on how much it gets used and what for.

https://www.python.org/dev/peps/pep-0411/#criteria-for-graduation is the only formal definition I can find for the process of moving from provisional to final, and it’s fairly strict on what would cause a provisional PEP to not get moved to final.

If upgrading wasn’t part of the discussion when PEP 610 was approved, then it’s reasonable to say it’s not in scope for the move to final. If the feature needs changing to handle upgrades, then we can always do a follow-up PEP that modifies the design to cater for that feature.

It’s @pradyunsg’s call (as BDFL-delegate) but I’d be inclined to not wait on a direct URL upgrade implementation, unless someone can propose a specific deadline by which that’s expected to be implemented.

63

I’m not too worried with the upgrade scenario because the URL is preserved in full, except for the fragments for which only the fragments that pip cares about are preserved (namely subdirectory). There might be interoperability issues one day but that would be because the URL part of PEP 508 is not normative, not because of PEP 610 itself.

64

Thanks for the clarification. Would it be allowed to specify additional fields in direct_url.json if we eventually find that more context is needed? (e.g. URL redirect destination.) The spec won’t need to be changed in an incompatible way if we are allowed to add to the format, and my worry wouldn’t matter in that case.

65

Adding optional fields to a json structure is something that is generally considered backward compatible for consumers of the data structure, so that should provide a sufficient evolution path indeed.

66

BTW, @pradyunsg, talking about things to record in .dist-info :slight_smile:
Do you think we can move forward and bring PEP 610 to final state?
I might then take a moment during the holidays to transform it into a spec at https://packaging.python.org/specifications/.

67

Yup. Adding the spec there this year, would be great. I think we can mark this as final once the spec is in the packaging.Python.org pages. :slight_smile:

68

I updated the PR at Add reference to PEP 610 by sbidoul · Pull Request #690 · pypa/packaging.python.org · GitHub with the full specification extracted from PEP 610.

69

And I resolved my previously blocking review, so this should be live soon :slight_smile:

70

@pradyunsg, gentle nudge for the last step, as we are now in a situation where the spec is published but the PEP is still Provisional.

1 Like
71

Thanks for the reminder. I filed a PR. :slight_smile:

1 Like
72

I’m wondering if any of the below is the preferred approach to remove the dist-info/direct_url.json during a package uninstallation…

  1. Should the direct_url.json file be added to RECORD during package installation?
  2. Or can importlib scan for the direct_url.json (for deletion) during a package uninstall, without it having been added to RECORD?
73

Yes.

importlib plays no part in the uninstallation of a package. The way pip handles uninstallation is that it removes all the files listed in the RECORD of a package.

1 Like