-
Notifications
You must be signed in to change notification settings - Fork 981
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
Implement 'latest' API and release-view endpoints #8615
Conversation
Nice! Just an FYI @bskinn, we'll hold off on giving this a full review until you take it out of draft status, but if you want input at any point feel free to @-mention me with specific questions. |
Yep, @di, that was my intention with draft status... no need to take maintainer time/attention until I've got it fleshed out. 👍 |
c8420e6
to
0760048
Compare
Ok, @di, I think this is ready for review on the implementation and tests. I'll augment the API docs as part of this PR, too--still TODO for now. (If you want to wait to review until I've finished the docs update, let me know.) One big question: with the arc I took on the code, I ended up implementing the logic directly in |
Looks like there is existing interest in having access to behaviors that would use |
Ok, @di, this is ready for review. Code/tests/docs are all completed for both the JSON and web UI I couldn't find anywhere to put a news snippet (as per, e.g., towncrier), or to include a CHANGELOG entry. Please advise if that's something I need to do, and how. |
Hi, @di -- I'm still interested in shepherding this PR through, if the features remain of interest. Please let me know if there's anything I can do on my end to facilitate the process. |
Need to add trailing-slash redirect, also.
Always want the browser to recheck this endpoint, in case the redirect target changes.
Still need to actually test the latest logic.
Switch latest from a redirect to /pypi/{name}/json, and instead duplicate the version-search logic. This should make `latest` robust against any future changes to the `json_project` logic. Implement latest-stable and latest-unstable logic.
Need to fix unstable query (or test?), is redirecting to the most recent stable version instead of most recent prerelease for project_with_pre
Apparently, the _pypi_ordering is a function of the order in which Releases are added to a Project. Seems potentially brittle.
JSON API views now directly return, rather than redirecting. Per pypi#8615 (review)
In the 'latest' views of views.py, pre-fetch the release from the project first, then handle appropriately given the possibility for None. Addresses the following PR review comments: - https://github.com/pypa/warehouse/pull/8615/files/ed0baa180d8bd628e80fcd37450c9d4d60dd5b9d?file-filters%5B%5D=.py#r619663916 - https://github.com/pypa/warehouse/pull/8615/files/ed0baa180d8bd628e80fcd37450c9d4d60dd5b9d?file-filters%5B%5D=.py#r619663799 - https://github.com/pypa/warehouse/pull/8615/files/ed0baa180d8bd628e80fcd37450c9d4d60dd5b9d?file-filters%5B%5D=.py#r619663874
For completeness, and to satisfy 100% coverage requirement.
Addresses pypi#8615 (comment). The database queries inline here may be duplicative; will check in a subsequent commit.
The 'latest' members off of the Project model now return fully-realized Release instances, making a subsequent database call unnecessary.
@ewjoachim, I've implemented your requested changes on a branch in my fork. See the PR over in my fork, for just this subset of the changes, here: bskinn#1 Separately, do you have any further thoughts on the web view showing, e.g., Unless I miss my guess, actually implementing display of For |
Latest json pr review
Ok, @ewjoachim, the auxiliary PR is merged. Ready for review starting with ee873dd. (Not sure what's up with the CI error -- by my read of |
The error is due to pypa/pip#9644 |
Should be removed before merging pypi#8615
Marked back as draft to remind about reverting c6f664a before merge |
This reverts commit c6f664a.
Any update on this? |
@ofek Given the extensive discussion ongoing about modernizing/standardizing the JSON API (see, e.g., here), I'm guessing this PR is on hold. (AFAIK the current JSON API is technically in legacy status.) If the feature set is still desired after all the turnover, I expect I'll need to revise the PR to fit into the new, standardized API, once it's finalized and implemented. (I haven't looked closely at the new PEP draft; it's possible that the functionality of this PR is already part of that plan, but I doubt it since the stated goal was just to PEPify the current API.) |
With the launch of the PEP 691 JSON API, are the semantics of this PR relevant any more? I haven't looked closely at what PEP691 provides in terms of version aliases. If so, and if the features are still of interest, I'll be happy to reimplement under the PEP691 rubric. Probably would close this PR and start from scratch. |
<looks closer> Oh. PEP691 deals with a JSON simple API. That's ~unrelated to this, isn't it? |
Closing as likely obsolete. |
Implements and closes #4663. See here for the semantics of the three new endpoints.
Per here and here, there was interest expressed in also having similar
latest
endpoints available for release views on the web UI. This PR has been expanded beyond #4663 to include all three of the analogous release-view redirects, at/project/{name}/latest
, etc.As the release calculations for the new
latest
JSON and web UI endpoints use the.latest_version
property that was previously defined onProject
, their implementations are coupled to the behavior used to serve the/project/{name}/
endpoint.Conversely, the
latest-stable
andlatest-unstable
endpoints for both the JSON and web UI are based on new functionality, and are not coupled to any other behaviors.Changelog/Announcement (?)N/A