Pre-PEP: Recording provenance of installed packages

Packaging
1

Hi all,

here is a Pre-PEP draft based on discussion in this topic. The PEP has no sponsor assigned.

Looking forward to reading your comments.

Thanks,
Fridolin

1 Like
2

I have seen on and off requests for this kind of record, so it might be of interest to others.

On the form, I think the tradition is to post the full text of the draft PEP here to start the conversation.
Before that, I suggest you follow the PEP 12 template - as noted on the PR, the text currently lacks a specification section.

You will also need to specify another metadata file than direct_url.json, because, as the spec notes, its presence signals that the distribution has been installed from a user-supplied direct URL, and it must not be created otherwise.

Coincidentally I recently opened a PR to extract the specification of the direct URL data structure into a standalone page, so you should be able to refer to it from your spec.

3 Likes
3

Indeed – based on my experience with PEP 704, I suggest we hold off on the PEP discussion until the PR is landed on the repository! :slight_smile:

1 Like
4

Just to note, I believe the convention (and our recommendation) has shifted slightly toward linking the drafted PEP in, e.g., a branch of the author’s fork of the PEPs repository instead of manually pasting the raw text in the OP, which:

  • Avoids the need to maintain and update two separate copies of the pre-PEP, with the one here typically drifting out of date
  • Provides a much more readable rendered form, while also allowing the viewing of the source text
  • Avoids the OP being a long wall of text obscuring the following discussion
  • Enables readers to cite specific lines or versions for feedback
  • Allows community members to submit PRs against the branch with proposed clarifications, fixes, changes, etc.
  • Keeps a record of everything in git history
  • Makes it easy for the author to submit the final version as a PR to the upstream PEPs repo when ready
2 Likes
5

I haven’t seen any recommendations being made (perhaps they’re happening on the PRs?), but I like having at least the initial text of the PEP proposal being posted in the context of the discussion. A PEP post should be very close to final review, not the early in-depth discussions.

I also prefer not reviewing PEPs until at least a sponsor has acknowledged it. Until then, it’s merely an idea, and not a proposal. (Roughly the difference between a discussion on python-ideas vs. python-dev, under the old mailing lists, though clearly that doesn’t make as much sense in the Packaging category.)

If PEP editors are reviewing the initial text and assigning a PEP number, and letting it be published on python.org, then in my mind they are now the sponsor. The point of requiring a sponsor is to prevent things getting to that stage without at least one “responsible person” (currently/previously defined as “a core dev”, though Packaging doesn’t and shouldn’t use that precise definition) signing off on the general quality of the proposal text and the fact that it’s at least been approved by initial discussions.

1 Like
6

FWIW, the PEP number was unassigned; since the draft needs more work and didn’t have a pre-existing sponsor.

I’ve retitled the topic to reflect that this draft isn’t assigned to a PEP number. (yay that I didn’t need to bother someone for this)

2 Likes
7

Just to clarify, in our initial reviews when the PEP PR was first submitted, we stated up front to the author that the PEP looked to need substantial re-work (and a sponsor, of course) to be considered for initial acceptance, pointing out the more salient issues; and suggested that they close the PR and discuss and iterate on it in a more appropriate venue (e.g. this thread, appropriately retitled), and then re-submit it once it’s complete and ready for official publication. I was going to post such on this thread as well, but held off repeating it here since others had already mentioned it, to avoid coming across as too harsh.

Also, my comment on a more appropriate thread responds to this further, specifically our new PR template checklist for new PEPs to help prevent this, and clarifying what happened with the PEP number.

If the PEP is already merged, then readers should of course be referred to the canonical, up-to-date, properly rendered version, rather than dumping an extra raw copy here (and plenty not to; see above). If it’s in-PR, the rendered preview should be linked, and otherwise, linking to a Gist or GitHub file in a fork branch is suggested for the benefits above.

1 Like
8

Thanks all involved for time and my sincere apologies for confusion about the initial submission. I would be not happy if it would affect proceeding with this proposal in a negative way.

Before proceeding, is anyone willing to sponsor this idea as a PEP? Thank you in advance.

9

No need to worry; we all make mistakes sometimes. At least from a PEP editor perspective, you’re welcome to re-submit once the PEP has been reworked to address the feedback, add the missing pieces, complete the items on the new PEP checklist, and attracted a baseline level of community interest and support.

Before finding an official core dev/PEP editor sponsor

You might want to consider putting out a more general call for any packaging community members willing to help provide feedback on the idea and the PEP, and guide you toward iterating toward a solid proposal ready for submission; and well as do what you can on your own to address the feedback already provided here and on the PR, and complete the missing items on the new PEP checklist. Once the PEP is in a more complete and fleshed-out state and has some community interest/support, it seems a lot more likely to attract sponsors.