#Python compatibility of a dependency cone

1 messages · Page 1 of 1 (latest)

steel cloak
#

None that I know of!

agile kestrel
#

sounds like something that could be done as an extension to a package manager, since most of the features are already there

kind bear
#

"dependency cone": I'll have to sneak that into my discussions and sound extra-smart 🙂

dawn narwhal
#

Locking the tree gives that info (requires-python is one of the pylock.toml fields, and I'm pretty sure the tool specific lock formats also record that detail).

kind bear
#

Which of the locking tools would you use to try this on a number of projects?

viscid shard
#

are you interested in specifically collecting information about the package in the dependency tree that have no source dist, or are you looking for compatibility in a wheel-only install?

#

is the input just a requirement or a specific lockfile, i.e. are you looking for the maximum compatibility range of a project, or the compatibility of specific set of locked versions?

#

hacky option: uv pip compile -p 3.x in a loop from Python 3.8 to e.g. 3.16 and see when its failing

$ echo torch | uv pip compile - -p 3.14
  × No solution found when resolving dependencies:
  ╰─▶ Because all versions of torch have no wheels with a matching Python ABI tag (e.g., `cp314`) and
      you require torch, we can conclude that your requirements are unsatisfiable.

      hint: You require CPython 3.14 (`cp314`), but we only found wheels for `torch` (v2.8.0) with the
      following Python ABI tags: `cp39`, `cp310`, `cp311`, `cp312`, `cp313`, `cp313t`
kind bear
#

I'm trying to look across a range of widely used libraries (25-50), and determine what versions of Python they can all be installed successfully on. This includes considering whether binary wheels are available for packages that need them.

viscid shard
#

uv pip compile is fast enough to run a scan across a range of version and libraries

kind bear
#

torch will throw the torch-wrench in the works perhaps

viscid shard
#

torch-wrench?

agile kestrel
kind bear
#

yes, sorry, i just made up that word 🙂

viscid shard
#

we can't cover gpu versions in the resolver, and torch is one of the few packages with a source distributions, but otherwise torch should resolve in the regular way

kind bear
#

@viscid shard I tried uv pip compile in Python 3.13 on a package that eventually needs google-re2==1.1.20240702. That version doesn't have 3.13 wheels, and if I try to install it in 3.13 it fails missing a C header. Is there a way to make uv pip compile fail for this case? Or should i use uv pip install to find those problems?

dawn narwhal
#

For "no wheels", --only-binary :all: can detect that.

For source build failures, only escalating to a full uv pip install on the locked requirements will detect it.

kind bear
#

The good news is that uv venv and uv pip install are fast enough to use on a wide swath of libraries

kind bear
#

After discussing this more with people, I've determined it's not a dependency cone, it's a four-dimensional dependency hyperboloid 😄

viscid shard
#

uv pip compile --no-build can limit to wheel-only, but it's also approximate

#

most source distributions build by themselves with the platform's equivalent of build-essential installed. but for google-re2, it's now not just the python version but also whether libre2-dev is installed

#
  • Building on Windows has not been tested yet and will probably fail.
    and operating system
#

the other case is that source distribution builds may depend on cpython internals that may or may not in future cpython releases