Skip to content

Comments

Add --find-links support for uv pip list#16103

Open
terror wants to merge 12 commits intoastral-sh:mainfrom
terror:pip-list-outdated
Open

Add --find-links support for uv pip list#16103
terror wants to merge 12 commits intoastral-sh:mainfrom
terror:pip-list-outdated

Conversation

@terror
Copy link
Contributor

@terror terror commented Oct 2, 2025

Resolves #16095

This PR fixes uv pip list --outdated so --find-links locations impact the latest-version lookup. This wires flat indexes through the registry client even under --no-index, lets LatestClient::find_latest evaluate the same compatibility filters across both Simple API and flat metadata, and adds an integration test that installs from scripts/links to show the higher local release is reported.

----- stderr -----
× No solution found when resolving dependencies:
╰─▶ Because first-local was not found in the provided package locations and second-local==0.1.0 depends on first-local, we can conclude that second-local==0.1.0 cannot be used.
╰─▶ Because first-local was not found in the package registry and second-local==0.1.0 depends on first-local, we can conclude that second-local==0.1.0 cannot be used.
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Do you know why these changed?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This path used to short-circuit with ErrorKind::NoIndex, but now since we're considering flat indexes (via --find-links), we end up getting a UnavailablePackage::NotFound rendering as 'not found in the package registry' instead.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think this wording is actually a bit confusing, this is implying we did a registry lookup (even though we supplied --no-index) as opposed to just looking at the directories/URLs provided by --find-links. Something to address for sure.

#[derive(Default, Debug, Clone, PartialEq, Eq)]
pub struct IndexUrls {
indexes: Vec<Index>,
flat_indexes: Vec<Index>,
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Was there a reason why we did not want to include flat_indexes here?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm not aware of any

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Unfortunately I really can't remember. I'm sure there's a reason for it. Probably because historically we didn't query flat indexes in the registry client? Something like that?

}

if results.is_empty() {
if self.index_urls.simple_indexes_disabled() {
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is a tad awkward, but this is here to keep the wording the same for the already_installed_local_path_dependent test.

@terror terror marked this pull request as ready for review October 3, 2025 16:02
@zanieb zanieb requested a review from charliermarsh October 8, 2025 13:46
#[derive(Default, Debug, Clone, PartialEq, Eq)]
pub struct IndexUrls {
indexes: Vec<Index>,
flat_indexes: Vec<Index>,
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm not aware of any

charliermarsh pushed a commit that referenced this pull request Oct 27, 2025
Made to address this comment:
#16103 (comment)

This PR sorts the distributions collected by
`FlatIndexClient::read_from_directory` (used for `--find-links`) so
results are ordered deterministically by filename and index.
@charliermarsh
Copy link
Member

It's actually a bit hard for me to reason about how --find-links works now, because we create the FlatIndexClient and pass that around, but we're now also passing the flat_indexes to the registry client... Are they now being indexed twice?

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

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

uv pip list --outdated does not use UV_FIND_LINKS

3 participants