Closed peytondmurray closed 1 year ago
Thanks for this issue @peytondmurray. Totally agree that this is an important thing for the conda-store api to return. Thinking of how we would like the api to return results. I like your proposed behavior. Thinking of how this can be done efficiently within a database.
I don't want to forget about this, and I'm interested in trying to implement this. I'll give it a shot this weekend and report back here.
I'm going to give some pushback on this feature. I've been working on implementing it. Suppose the endpoint returns:
{
license: "...",
name: "...",
channel_id: "...",
summary: "...",
versions: [
["package_id", "version_str"],
"..."
]
}
A few of my concerns:
/package/
is already taken and Id prefer to not add another not totaly orthogonal endpoint.I agree that right now the api is not fast enough making this take awhile. I need to speed up these queries.
Got more color in our meeting today. We will limit the scope to individual packages.
E.g. /api/v1/package/<channel-identifier>/<package-name>
@costrouc is this still valid?
The API changed since the issue was open, and the performance were greatly improved since then.
Do we still want this feature of listing versions of a given package ?
perhaps not - we can close and if needed we can reopen or make a better scoped issue
Yeah I agree on closing this issue. When @pierrotsmnrd significantly improved the performance of the package api I don't think there is as much of a use case. Since you can just normally query the api.
Current Behavior
Right now, the
/api/v1/package/
endpoint fetches the packages which are available for the user to install. Currently, I can control the list of packages returned to me by using the appropriate query parameters. For example, if I send a GET to/api/v1/package/?page=1&size=10&distinct_on=name&distinct_on=version&sort_by=name
, the response is a list of results which have distinct names and versions:For conda-store integration in Gator this is not optimal, because packages can have many versions; for each single fetch request, only a few distinct packages are returned, with most of the results just different versions of the same package.
Proposed behavior
Instead of treating distinctly-versioned packages as separate treat them as a single package, and return a list of installable versions for each uniquely named package:
I haven't yet worked out the implications for cases where different versions of a package are provided on different channels, or handling different builds, but I just wanted to get the discussion going. I think if the user wants more information about a specific package (individual version information, for example), they can use the
search
query parameter on the/api/v1/package/
endpoint. This change would greatly improve the user experience for browsing packages with the Gator JupyterLab extension.