Skip to content
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

Important project links are pushed down into the "unverified details" section #15903

Closed
GergelyKalmar opened this issue May 4, 2024 · 8 comments
Labels
bug 🐛 requires triaging maintainers need to do initial inspection of issue

Comments

@GergelyKalmar
Copy link

Describe the bug
I used to be able to go to important project pages from the top of the package detail page (e.g. homepage, changelog). For some reason these links are now all under the "Unverified details" section, which is under the "Maintainers" section, which pushes these links below the fold, requiring scrolling and hunting for these links. I do not understand the difference between "Verified details" and "Unverified details", nor could I find any information about this change whatsoever (checked on the PyPI blog, GitHub issues, Google search, found nothing).

Expected behavior
I would expect that I can find the project links near the top of a package detail page, preferably above the fold.

To Reproduce
Go to any package detail page on PyPI (e.g. https://pypi.org/project/selenium/).

@GergelyKalmar GergelyKalmar added bug 🐛 requires triaging maintainers need to do initial inspection of issue labels May 4, 2024
@cofiem
Copy link
Contributor

cofiem commented May 5, 2024

It looks like the top-level issue for 'verified project details' is this one: #8635

I do agree that some kind of documentation for what verified means and how attributes of a project are verified, would be good. Maybe an entry on the PyPI help page? Or possibly some more details on https://docs.pypi.org?

@woodruffw
Copy link
Member

Yep, #8635 is probably the best top-level issue tracker.

To summarize the problem, there are two kinds of project metadata: there's metadata that PyPI knows a priori about the project based on the user(s) that own it, and there's metadata that PyPI receives about the project each time a new release/distribution is created.

The former is "verified" in the sense that PyPI knows what accounts are registered and what projects they own; the latter is "unverified" in the sense that any distribution can put whatever it wants in its metadata, such as misleading "homepage" links or incorrect GitHub repositories to inflate the rendered GitHub statistics. The two were previously conflated, resulting in user confusion about which pieces of rendered project information were "checked" by PyPI versus blindly trusted from the project's metadata.

The long term plan here is to lift more and more pieces of "unverified" metadata into the "verified" section. The first step in that process was to introduce trusted publishing, which provides a verifiable link to the source repository that can be cross-checked against the project's metadata. The second (ongoing) step is to finalize and implement PEP 740, which will expose the trusted publisher metadata for downstream consumption and stabilize it so that PyPI can reliably compare it to project metadata.

TL;DR: The split between the two was made to clarify the relationship between the things PyPI knows and doesn't know about each project. Over time, the amount of things in the "unverified" section should decrease, meaning fewer things "below the fold" in your particular case.

@GergelyKalmar
Copy link
Author

That all makes perfect sense, however, why make this change then before https://peps.python.org/pep-0740/ is accepted and implemented? If I understand you correctly there seems to be no way currently to add most of the existing project links to the "verified" section, which essentially worsens the user experience for everyone (package maintainers and users alike). I'd suggest to revert this change at least until there is a canonical way for package maintainers to get project links into the "verified" section.

@woodruffw
Copy link
Member

That all makes perfect sense, however, why make this change then before https://peps.python.org/pep-0740/ is accepted and implemented?

I think the answer to this is that, regardless of PEP 740, PyPI wants to better distinguish what is and isn't pre-verified about the package. In other words: my goal is to make more things verified with PEP 740, but even without it there's value in communicating the distinction to users.

I agree that there's value in keeping things above the fold (for a majority of clients), however. I don't have any great ideas for doing this that don't involve reducing the level of detail in the maintainers' panel, though. Maybe PyPI could have a separate RHS panel as well?

@UlionTse

This comment was marked as spam.

@sr-murthy
Copy link

Sorry for jumping in, but I'm a package developer and maintainer (https://pypi.org/project/continuedfractions/) affected by this issue - I have several links on the package page that are showing up as unverified including the GitHub project homepage and the documentation home page (screenshot attached).
Screenshot 2024-06-07 at 20 02 51

These are predefined in my project TOML. Not urgent, but would be nice to have a solution for. The main issue with this, for me, is that it creates an impression of a lack of trust in the package if important details of the package are flagged as "unverified".

@woodruffw
Copy link
Member

To close a loop here: PyPI is now matching project URLs against trusted publishers, meaning that more projects should be seeing their metadata marked as "verified" as they perform new releases.

@di
Copy link
Member

di commented Sep 19, 2024

Going to close this as a duplicate of #8635. We're at the point where almost all metadata can now be verified, with the last piece being #16597.

@di di closed this as completed Sep 19, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug 🐛 requires triaging maintainers need to do initial inspection of issue
Projects
None yet
Development

No branches or pull requests

6 participants