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

API for fetching latest and stable versions #4663

Open
techtonik opened this issue Sep 4, 2018 · 13 comments
Open

API for fetching latest and stable versions #4663

techtonik opened this issue Sep 4, 2018 · 13 comments

Comments

@techtonik
Copy link

What's the problem this feature will solve?

Tools could use simple lookup logic for checking their latest and stable versions. The way it is currently done in pip is crazy:

https://github.com/pypa/pip/blob/35d51f1f405f6f31d68c800e73307686ec029254/src/pip/_internal/utils/outdated.py#L104-L118

Describe the solution you'd like

It should be as simple as fetching https://pypi.org/pypi/pip/latest/json or https://pypi.org/pypi/pip/stable/json endpoints.

@bskinn
Copy link
Contributor

bskinn commented Sep 18, 2020

I don't know what fraction of PyPI's bandwidth is consumed by JSON requests, but I feel a bit bad pulling down the entire /pypi/{pkg}/json endpoint for a project/package when all I want is to check the most recent version number.

@di
Copy link
Member

di commented Sep 18, 2020

@bskinn Most of the bandwidth is consumed by distributions (files), not JSON. And even then, 90-something percent of it is cached by our CDN -- so don't feel bad 🙂

That said, this API makes sense to me and would be relatively easy to implement. The hard part is getting it right.

Something like the following seems to cover all use cases to me:

  • /latest/json Latest non-prerelease if available, otherwise the latest prerelease
  • /latest-stable/json Latest non-prerelease
  • /latest-unstable/json Latest version including prereleases

Should just be redirects to the actual versions? E.g. /pypi/pip/latest/json -> /pypi/pip/20.1.1/json?

@bskinn
Copy link
Contributor

bskinn commented Sep 18, 2020

<nod>, those three, and their names, make sense to me.

Main catch scenarios are (1) for all three, if no versions are available, and (2) specifically for latest-stable, in the case that no non-prerelease versions are available?

@di
Copy link
Member

di commented Sep 18, 2020

I imagine that they'd be 404 instead in that case, same as if the project didn't actually exist.

Another question, should any of these include yanked releases? I think not.

@bskinn
Copy link
Contributor

bskinn commented Sep 18, 2020

Yeah, I figured they'd 404. Not knowing the warehouse codebase that well, though, I wasn't sure if there's already machinery there that would cleanly handle this particular failure mode & kick out the 404.

Agreed, I figure it should mimic the behavior of pip in dealing with yanked projects. Since this API call is intrinsically an operation where the user can't indicate a specific release, yanked releases should never be returned.

@bskinn
Copy link
Contributor

bskinn commented Sep 23, 2020

If I read the model code correctly, Project.latest_version would supply the correct version for /latest/json/, including masking-out of any yanked releases.

If so (and if this is the right place in the codebase to implement the search), could just implement two variations that provide latest-stable and latest-unstable?

@di
Copy link
Member

di commented Sep 23, 2020

That would make sense to me!

@bskinn
Copy link
Contributor

bskinn commented Sep 24, 2020

Ok... I've been poking at this, and I think I'll try to put together a PR for it.

One question, @di -- what is the semantic meaning of a NULL value for Release.is_prerelease?

Project.latest_version uses .nullslast(), which seems to suggest that there may be some edge cases where returning such a Release is desired. But, I'm wondering whether a new Project.latest_stable_version should also use .nullslast() in the same way, or if it should exclude .is_prerelease NULLs from the query altogether.

Regardless of the above, I figure Project.latest_unstable_version should follow .latest_version and also use .nullslast().

@di
Copy link
Member

di commented Sep 24, 2020

Looks like it was added in #3470

@bskinn
Copy link
Contributor

bskinn commented Sep 24, 2020

Maybe it's a guard against a mangled table? Regardless, looks like there's no need to consider the NULL case; and shouldn't hurt anything to just keep the .nullslast() in the call flow, in case. Thanks!

@graingert
Copy link
Contributor

I'd also like to be able to link to the latest and stable versions:

.. image:: https://img.shields.io/pypi/v/modernize/latest?logo=pypi
    :alt: PyPI Latest
    :target: https://pypi.org/project/modernize/latest
.. image:: https://img.shields.io/pypi/v/modernize/stable?logo=pypi
    :alt: PyPI Stable
    :target: https://pypi.org/project/modernize/stable

@EwoutH
Copy link

EwoutH commented Jul 22, 2024

I would still find this useful!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging a pull request may close this issue.

5 participants