Skip to content

resolving a circular dependency as lowest results in an older version of the project being fetched #16844

@neutrinoceros

Description

@neutrinoceros

Summary

When experimenting with --resolution=lowest for astropy's complete dependency graph, I hit a diabolical edge case, where astropy has an optional dependency on asdf-astropy>=0.3, which itself requires astropy>=5.0.4 (astropy's current version number is in the 8.0.0dev+...). Apparently, uv fails to recognize that astropy is the package being resolved for, and it attempts to build v5.0.4 from source. This would already be a waste of time even if it worked, but it doesn't, making it harder to ignore.

example logs
relevant excerpt :

Building astropy==5.0.4
  × Failed to download and build `astropy==5.0.4`
  ├─▶ Failed to resolve requirements from `build-system.requires`
  ├─▶ No solution found when resolving: `setuptools`, `setuptools-scm>=6.2`,
  │   `wheel`, `cython==0.29.22`, `markupsafe==2.0.1`, `jinja2==3.0.3`,
  │   `oldest-supported-numpy`, `extension-helpers`
  ╰─▶ Because markupsafe==2.0.1 has no usable wheels and you require
      markupsafe==2.0.1, we can conclude that your requirements are
      unsatisfiable.

      hint: Wheels are required for `markupsafe` because building from
      source is disabled for `markupsafe` (i.e., with `--no-build-package
      markupsafe`)
  help: `astropy` (v5.0.4) was included because `asdf-astropy` (v0.3.0)
        depends on `astropy`

To add insult to injury, astropy's version number is dynamic...

I suppose at this point, the resolver cannot really be expected to do better than taking a bet and just assume that the version of astropy being built will satisfy the requirements. I think this would be fine as long as the assumption is checked after we're done building astropy.

I do note that there's a known workaround we can use by making astropy requiring a more recent version of asdf-astropy, but I think that's ultimately a hack, and only works because we end up downloading older versions of astropy that have matching wheels, so I'd be interested to see if there's a chance to resolve the root issue in uv instead.

Unfortunately I couldn't reproduce this locally on macOS (amr64), so I don't have the ability to reduce my reproducer yet.
Possibly related, but I don't think that's quite a duplicate: #16372

Platform

Seen on ubuntu ubuntu-24.04

Version

uv==0.9.11

Python version

3.11

Metadata

Metadata

Assignees

No one assigned

    Labels

    questionAsking for clarification or support

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions