Fix uv sync --no-sources not switching from editable to registry installations

[yumeminami]

Summary

Fixes issue #15190 where uv sync --no-sources fails to switch from editable to registry package installations. The problem occurred because the installer's satisfaction check didn't consider the --no-sources flag when determining if an existing editable installation was compatible with a registry requirement.

Solution

Modified RequirementSatisfaction::check() to reject non-registry installations when SourceStrategy::Disabled and the requirement is from registry. Added SourceStrategy parameter threading through the entire call chain from commands to the satisfaction check to ensure consistent behavior between uv sync --no-sources and uv pip install --no-sources.

[zanieb]

Hey thanks for taking a swing at this!

Naively, I think I'd expect this to be implemented in SitePackages instead? e.g.,

uv/crates/uv-installer/src/site_packages.rs

Lines 291 to 298 in c19a294

	/// Returns if the installed packages satisfy the given requirements.
	pub fn satisfies_spec(
	&self,
	requirements: &[UnresolvedRequirementSpecification],
	constraints: &[NameRequirementSpecification],
	overrides: &[UnresolvedRequirementSpecification],
	markers: &ResolverMarkerEnvironment,
	) -> Result<SatisfiesResult> {

uv/crates/uv-installer/src/site_packages.rs

Lines 386 to 393 in c19a294

	/// Like [`SitePackages::satisfies_spec`], but with resolved names for all requirements.
	pub fn satisfies_requirements<'a>(
	&self,
	requirements: impl ExactSizeIterator<Item = &'a Requirement>,
	constraints: impl Iterator<Item = &'a Requirement>,
	overrides: impl Iterator<Item = &'a Requirement>,
	markers: &ResolverMarkerEnvironment,
	) -> Result<SatisfiesResult> {

Did you look at that? Does that not work for some reason?

[yumeminami]

@zanieb

After reviewing the uv sync call chain, I found that it does not use SitePackages::satisfies_spec() or
satisfies_requirements(). Instead, it follows this path:

uv sync → operations::install() → Planner::build() → RequirementSatisfaction::check()

The bug is in RequirementSatisfaction::check() at

uv/crates/uv-installer/src/satisfies.rs

Lines 33 to 38 in c19a294

	RequirementSource::Registry { specifier, .. } => {
	if specifier.contains(distribution.version()) {
	return Self::Satisfied;
	}
	Self::Mismatch
	}

Why Not Pass SourceStrategy?

Initially, I considered passing SourceStrategy to RequirementSatisfaction::check(), but this would require:

1. Extensive API changes: Modifying function signatures across multiple layers
2. High impact: Affecting many unrelated code paths
3. Complex propagation: Threading the parameter through the entire call chain

[yumeminami]

@zanieb

same problem use uv pip install --no-sources

(test_uv_pip_no_sources) ➜  test_uv_pip_no_sources git:(fix/sync-no-sources-editable-switch) ✗ cat pyproject.toml             
[project]
name = "test_no_sources"
version = "0.0.1"

dependencies = ["git_mcp_server"]

[tool.uv.sources]
git_mcp_server = { path = "./git_mcp", editable = true }


(test_uv_pip_no_sources) ➜  test_uv_pip_no_sources git:(fix/sync-no-sources-editable-switch) ✗ head git_mcp/pyproject.toml
[project]
name = "git_mcp_server"
version = "0.1.9"
description = "Git MCP Server - Unified command-line tool for managing Git repositories across GitHub and GitLab"
readme = "README.md"
requires-python = ">=3.13"
dependencies = [
    "python-gitlab>=4.4.0",
    "PyGithub>=2.1.0",
    "click>=8.1.0",
    
   
(test_uv_pip_no_sources) ➜  test_uv_pip_no_sources git:(fix/sync-no-sources-editable-switch) ✗ uv pip install --no-sources git_mcp_server
Resolved 64 packages in 48ms
Installed 1 package in 7ms
 + git-mcp-server==0.1.8
(test_uv_pip_no_sources) ➜  test_uv_pip_no_sources git:(fix/sync-no-sources-editable-switch) ✗ uv pip install -e .                       
Resolved 65 packages in 24ms
      Built test-no-sources @ file:///Users/wingmunfung/workspace/uv/test_uv_pip_no_sources
Prepared 1 package in 520ms
Uninstalled 2 packages in 4ms
Installed 2 packages in 3ms
 - git-mcp-server==0.1.8
 + git-mcp-server==0.1.9 (from file:///Users/wingmunfung/workspace/uv/test_uv_pip_no_sources/git_mcp)
 ~ test-no-sources==0.0.1 (from file:///Users/wingmunfung/workspace/uv/test_uv_pip_no_sources)
 
 
(test_uv_pip_no_sources) ➜  test_uv_pip_no_sources git:(fix/sync-no-sources-editable-switch) ✗ uv pip install --no-sources git_mcp_server
Audited 1 package in 15ms


(test_uv_pip_no_sources) ➜  test_uv_pip_no_sources git:(fix/sync-no-sources-editable-switch) ✗ uv pip show git_mcp_server                
Name: git-mcp-server
Version: 0.1.9
Location: /Users/wingmunfung/workspace/uv/test_uv_pip_no_sources/.venv/lib/python3.13/site-packages
Editable project location: /Users/wingmunfung/workspace/uv/test_uv_pip_no_sources/git_mcp
Requires: click, gitpython, httpx, keyring, mcp, pre-commit, pydantic, pygithub, python-gitlab, pyyaml, rich, tool
Required-by: test-no-sources
(test_uv_pip_no_sources) ➜  

I think the git-mcp-server version should be 0.1.8 while I run v pip install --no-sources git_mcp_server

[zanieb]

Yes sorry, RequirementSatisfaction::check and the Planner::build methods are relevant too.

I'm not sure if we need to propagate the source strategy? That should be reflected in the resolution?

I think we should be able to tell if an installed distribution matches the resolution. Naively, I'd image we want something like this?

diff --git a/crates/uv-installer/src/satisfies.rs b/crates/uv-installer/src/satisfies.rs
index b7e824202..48709e2cc 100644
--- a/crates/uv-installer/src/satisfies.rs
+++ b/crates/uv-installer/src/satisfies.rs
@@ -31,7 +31,9 @@ impl RequirementSatisfaction {
         match source {
             // If the requirement comes from a registry, check by name.
             RequirementSource::Registry { specifier, .. } => {
-                if specifier.contains(distribution.version()) {
+                if matches!(distribution, InstalledDist::Registry { .. })
+                    && specifier.contains(distribution.version())
+                {
                     return Self::Satisfied;
                 }
                 Self::Mismatch

[yumeminami]

@zanieb

Thank you for your feedback.

After applying your modification, I was able to install the package again using uv sync --no-sources instead of getting no output.

However, running uv pip install --no-sources will throws an exception.

Upon closer inspection, I found that the call chains for sync and pip install differ. In particular, pip install uses a CandidateSelector, whose CandidateSelector::get_installed() strategy is inconsistent with the matching logic in RequirementSatisfaction::check().

This mismatch causes the resolver to treat the package as ResolvedDist::Installed(does not check it is a Url or a Registry), while RequirementSatisfaction::check() flags it as mismatched—leading to a panic.

(test_uv_sync) ➜ test_uv_sync uv-dev pip install --no-sources anyio -v
DEBUG uv 0.8.9+2 (250c3a746 2025-08-13)
DEBUG Searching for default Python interpreter in virtual environments
DEBUG Found `cpython-3.13.2-macos-aarch64-none` at `/Users/wingmunfung/test_uv_sync/.venv/bin/python3` (active virtual environment)
DEBUG Using Python 3.13.2 environment at: .venv
DEBUG Acquired lock for `.venv`
DEBUG Registry check: distribution=Url(InstalledDirectUrlDist { name: PackageName("anyio"), version: "4.3.0", direct_url: LocalDirectory { url: "file:///Users/wingmunfung/test_uv_sync/local_dep", dir_info: DirInfo { editable: Some(true) }, subdirectory: None }, url: DisplaySafeUrl { scheme: "file", cannot_be_a_base: false, username: "", password: None, host: None, port: None, path: "/Users/wingmunfung/test_uv_sync/local_dep", query: None, fragment: None }, editable: true, path: "/Users/wingmunfung/test_uv_sync/.venv/lib/python3.13/site-packages/anyio-4.3.0.dist-info", cache_info: Some(CacheInfo { timestamp: Some(Timestamp(SystemTime { tv_sec: 1755059554, tv_nsec: 377749146 })), commit: None, tags: None, env: {}, directories: {"src": None} }) }), specifier=VersionSpecifiers([]), version="4.3.0"
DEBUG At least one requirement is not satisfied: anyio
DEBUG Using request timeout of 30s
DEBUG Solving with installed Python version: 3.13.2
DEBUG Solving with target Python version: >=3.13.2
DEBUG Adding direct dependency: anyio*
DEBUG Found stale response for: https://pypi.org/simple/anyio/
DEBUG Sending revalidation request for: https://pypi.org/simple/anyio/
DEBUG Found not-modified response for: https://pypi.org/simple/anyio/
DEBUG Found installed version of anyio==4.3.0 (from file:///Users/wingmunfung/test_uv_sync/local_dep) that satisfies *
DEBUG Searching for a compatible version of anyio (*)
DEBUG Found installed version of anyio==4.3.0 (from file:///Users/wingmunfung/test_uv_sync/local_dep) that satisfies *
DEBUG Selecting: anyio==4.3.0 [installed] (installed)
DEBUG Tried 1 versions: anyio 1
DEBUG marker environment resolution took 0.248s
Resolved 1 package in 251ms
DEBUG Registry check: distribution=Url(InstalledDirectUrlDist { name: PackageName("anyio"), version: "4.3.0", direct_url: LocalDirectory { url: "file:///Users/wingmunfung/test_uv_sync/local_dep", dir_info: DirInfo { editable: Some(true) }, subdirectory: None }, url: DisplaySafeUrl { scheme: "file", cannot_be_a_base: false, username: "", password: None, host: None, port: None, path: "/Users/wingmunfung/test_uv_sync/local_dep", query: None, fragment: None }, editable: true, path: "/Users/wingmunfung/test_uv_sync/.venv/lib/python3.13/site-packages/anyio-4.3.0.dist-info", cache_info: Some(CacheInfo { timestamp: Some(Timestamp(SystemTime { tv_sec: 1755059554, tv_nsec: 377749146 })), commit: None, tags: None, env: {}, directories: {"src": None} }) }), specifier=VersionSpecifiers([VersionSpecifier { operator: Equal, version: "4.3.0" }]), version="4.3.0"
DEBUG Requirement installed, but mismatched: 
Installed: Url(InstalledDirectUrlDist { name: PackageName("anyio"), version: "4.3.0", direct_url: LocalDirectory { url: "file:///Users/wingmunfung/test_uv_sync/local_dep", dir_info: DirInfo { editable: Some(true) }, subdirectory: None }, url: DisplaySafeUrl { scheme: "file", cannot_be_a_base: false, username: "", password: None, host: None, port: None, path: "/Users/wingmunfung/test_uv_sync/local_dep", query: None, fragment: None }, editable: true, path: "/Users/wingmunfung/test_uv_sync/.venv/lib/python3.13/site-packages/anyio-4.3.0.dist-info", cache_info: Some(CacheInfo { timestamp: Some(Timestamp(SystemTime { tv_sec: 1755059554, tv_nsec: 377749146 })), commit: None, tags: None, env: {}, directories: {"src": None} }) }) 
Requested: Registry { specifier: VersionSpecifiers([VersionSpecifier { operator: Equal, version: "4.3.0" }]), index: None, conflict: None }

thread 'main2' panicked at crates/uv-installer/src/plan.rs:150:17:
internal error: entered unreachable code: Installed distribution could not be Found in site-packages: anyio==4.3.0 (from file:///Users/wingmunfung/test_uv_sync/local_dep)
Note: Run with `RUST_BACKTRACE=1` environment variable to display a backtrace
DEBUG Released lock at `/Users/wingmunfung/test_uv_sync/.venv/.lock`

Thread 'main' panicked at /Users/wingmunfung/workspace/uv/crates/uv/src/lib.rs:2300:10:
Tokio executor failed, was there a panic?: Any { .. }

[yumeminami]

uv/crates/uv-installer/src/plan.rs

Lines 94 to 102 in 78c8c71

	// 1. Apparently, we never return direct URL distributions as [`ResolvedDist::Installed`].
	// If you trace the resolver, we only ever return [`ResolvedDist::Installed`] if you go
	// through the [`CandidateSelector`], and we only go through the [`CandidateSelector`]
	// for registry distributions.
	//
	// 2. We expect any distribution returned as [`ResolvedDist::Installed`] to hit the
	// "Requirement already installed" path (hence the `unreachable!`) a few lines below it.
	// So, e.g., if a package is marked as `--reinstall`, we _expect_ that it's not passed in
	// as [`ResolvedDist::Installed`] here.

Doesn’t the log above violate the assumption in the comment #15234 (comment)?

DEBUG Found installed version of anyio==4.3.0 (from file:///Users/wingmunfung/test_uv_sync/local_dep) that satisfies *
DEBUG Selecting: anyio==4.3.0 [installed] (installed)
DEBUG Requirement installed, but mismatched: 
Installed: Url(InstalledDirectUrlDist { name: PackageName("anyio"), version: "4.3.0", direct_url: LocalDirectory { url: "file:///Users/wingmunfung/test_uv_sync/local_dep", dir_info: DirInfo { editable: Some(true) }, subdirectory: None }, url: DisplaySafeUrl { scheme: "file", cannot_be_a_base: false, username: "", password: None, host: None, port: None, path: "/Users/wingmunfung/test_uv_sync/local_dep", query: None, fragment: None }, editable: true, path: "/Users/wingmunfung/test_uv_sync/.venv/lib/python3.13/site-packages/anyio-4.3.0.dist-info", cache_info: Some(CacheInfo { timestamp: Some(Timestamp(SystemTime { tv_sec: 1755059554, tv_nsec: 377749146 })), commit: None, tags: None, env: {}, directories: {"src": None} }) }) 
Requested: Registry { specifier: VersionSpecifiers([VersionSpecifier { operator: Equal, version: "4.3.0" }]), index: None, conflict: None }

[yumeminami]

@zanieb

Could you help me look into this issue?

[zanieb]

Hey, I'll look when I get a chance — I've been a bit busy and don't know the answer off the top of my head so I'll need to dig into the problem.

[charliermarsh]

I think that comment is probably wrong. I think CandidateSelector::select can return InstalledDirectUrlDist if you have an already-installed URL that matches a user requirement (e.g., you have anyio @ 4.3.0 installed from Git, and you run uv pip install anyio).

I think the error you're seeing is because you changed the logic in the install plan, but you need to make a corresponding change in the resolver, such that when resolving, we don't choose the already-installed URL distribution if the user didn't request a URL. In other words: you need to reflect the change in both the install plan and the resolver, and modifying satisfies only affects the install plan.

It's not totally clear to me whether we want that behavior, though. It's clear for the uv sync case, but like, if we make this change as described, then uv pip install git+https://github.com/agronholm/anyio followed by uv pip install anyio would uninstall the Git-based anyio and then reinstall it from PyPI. That would be a breaking change, so we probably make sure we want to do that before finishing the PR.

(Alternatively, if we could somehow make this change only for the uv sync case, that'd be easier to ship.)

[yumeminami]

@charliermarsh

My current change is limited to handling uv sync --no-sources only:

1. Check whether the SourceStrategy is false.
2. Collect the registry packages from the resolution.
3. Check for already InstalledDist::Url(_)/InstalledDist::LegacyEditable(_) packages.
4. Mark them for reinstallation.

Do you think this scoped fix is small enough for now?

I also experimented with modifying the resolver. Specifically, I tried passing SourceStrategy into the CandidateSelector, and alternatively, filtering out InstalledDist::Url and InstalledDist::LegacyEditable in CandidateSelector::get_installed() so they’re no longer considered as installed. This does solve the issue for pip install --no-sources, but it comes with some drawbacks:

• CandidateSelector is used in many modules, so the change could have unintended consequences.
• It requires passing parameters deeply, which means modifying many call sites.
• It affects a large number of unit tests.

[charliermarsh]

@yumeminami -- Sorry, will get back to you soon, this is on my list.

[charliermarsh]

@yumeminami -- What do you think of #15450? It's a slightly different approach whereby the check logic uses different rules depending on whether we're using uv pip or uv sync.

[yumeminami]

@charliermarsh

Thanks your feedback!

I took a look of #15450 and I think it did the thing like as discussed in #15234 (comment) by passing the SyncModel(Sourcestrategy in the comment) argument through multiple functions until it reaches RequirementSatisfaction::check.

I have some suggestions:

1. SyncModel implies it's about uv sync? I'm not sure, but it actually controls the "packet matching strategy" and I feel like Stateful and Stateless might be a bit ambiguous. And I sugget use this InstallationStrategy, what do you think?

/// Defines the strategy for determining whether an installed package satisfies a requirement.
  ///
  /// This enum controls how the package installer validates existing installations against
  /// new requirements, particularly when there are differences in source types (registry vs local).
  #[derive(Debug, Clone, Copy, PartialEq, Eq)]
  pub enum InstallationStrategy {
      /// Permissive strategy: Accept existing installations even if source type differs.
      ///
      /// This strategy mirrors traditional pip behavior, where already-installed packages
      /// are reused if they satisfy the version requirements, regardless of how they were
      /// originally installed. For example:
      /// - If `./path/to/package` is installed and later `package` is requested from registry,
      ///   the existing installation will be reused if the version matches.
      /// - This enables incremental package management where users can mix installation sources.
      ///
      /// Used by: `uv pip install`, `uv pip sync`
      Permissive,

      /// Strict strategy: Require exact source type matching between installed and requested packages.
      ///
      /// This strategy enforces that the installation source must match the requirement source.
      /// It prevents reusing packages that were installed from different sources, ensuring
      /// declarative and reproducible environments. For example:
      /// - If an editable package is installed but a registry version is requested,
      ///   the editable installation will be replaced with the registry version.
      /// - This is essential for `--no-sources` scenarios where local installations
      ///   should be replaced with registry equivalents.
      ///
      /// Used by: `uv sync`, `uv run`, `uv tool run`
      Strict,
  }

2. Does this PR fix the issue in Fix uv sync --no-sources not switching from editable to registry installations #15234 (comment) about pip install --no-soures? If the checks detect a Statefule condition and a distribution mismatch InstalledDist::Registry { .. }, should we prompt the user?

[yumeminami]

I’ve attempted to add SyncModel as a property of the SitePackages struct so that we could update the construction of SitePackages instances instead of modifying multiple function signatures and calls.

And I found Rust does not support default parameters in functions—by default, Stateful is used, and Stateless must be explicitly passed when needed. This makes the solution more involved than the approach in PR #15450.

😢 😢

[charliermarsh]

Yeah I think your names are better (mine were sort of lazy, to validate the idea).

I think this should only apply to uv sync personally, and even uv pip install --no-sources should have the same behavior whereby we "accept" the implicit registry requirement.

We might (?) need to thread this through to the candidate selector / resolver as well, is the only other downside... That's why some tests are failing, I think.

[yumeminami]

Yeah, I agree.

If we want the uv pip install --no-sources has the same behave as uv sycn --no-sources, the candidate selector strategy need to align the RequirementSatisfaction::check func.

[yumeminami]

@charliermarsh

Later, I will base #15450 then modify the candidate selector strategy and new a pr again.(maybe Tuesday or Wednesday）

[yumeminami]

@charliermarsh

Now th PR should fix uv sync --no-sources and uv pip install --no-sources.

[yumeminami]

how to rerun the CI and why the install python job will fail?

[charliermarsh]

@yumeminami -- Sorry, I was trying to convey that I think this should only affect uv sync (and uv pip install should be unchanged). Do you agree?

[yumeminami]

Agree.

…

On Sun, 14 Sept 2025 at 10:06, Charlie Marsh ***@***.***> wrote: *charliermarsh* left a comment (astral-sh/uv#15234) <#15234 (comment)> @yumeminami <https://github.com/yumeminami> -- Sorry, I was trying to convey that I think this should *only* affect uv sync (and uv pip install should be unchanged). Do you agree? — Reply to this email directly, view it on GitHub <#15234 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AQDB34QOSDH6KYLOJZ6Q7EL3STER3AVCNFSM6AAAAACDV3WXSKVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZTEOBZGA4DONJSG4> . You are receiving this because you were mentioned.Message ID: ***@***.***>

[charliermarsh]

Okay thanks. I will revisit this and look to get it merged.

[charliermarsh]

Okay, this should be good to go. It only changes the behavior for uv sync (and uv run, which calls uv sync behind the hood), where we have full control over the sources and resolution.

[yumeminami]

@charliermarsh thanks!