uv pip compile error message not readable.

[Czaki]

I try to play with --resolution=lowest for minimum requirements testing.
However, it fails with following traceback. As the same command passes with resolution=lowest-direct it looks like there is a problem with some indirect dependecy dependecies not pinning setuptools to proer version.

However traceback do not consin any information about dependecy path to problematic package.
It will be nice to add such information. It will be also nice to not try using python2 only packages.

uv pip compile -p 3.8 -o resources/constraints/constraints_py3.8_min_req.txt pyproject.toml --extra testing --extra pyqt5 --resolution=lowest -U       
error: Failed to download and build: setuptools==0.7.2
  Caused by: Failed to build: setuptools==0.7.2
  Caused by: Build backend failed to determine extra requires with `build_wheel()`:
--- stdout:

--- stderr:
Traceback (most recent call last):
  File "<string>", line 4, in <module>
  File "/home/czaki/.cache/uv/built-wheels-v0/pypi/setuptools/0.7.2/50gYfHetQiLPzvTHRj8sH/setuptools-0.7.2.tar.gz/setuptools/__init__.py", line 2, in <module>
    from setuptools.extension import Extension, Library
  File "/home/czaki/.cache/uv/built-wheels-v0/pypi/setuptools/0.7.2/50gYfHetQiLPzvTHRj8sH/setuptools-0.7.2.tar.gz/setuptools/extension.py", line 5, in <module>
    from setuptools.dist import _get_unpatched
  File "<frozen importlib._bootstrap>", line 991, in _find_and_load
  File "<frozen importlib._bootstrap>", line 975, in _find_and_load_unlocked
  File "<frozen importlib._bootstrap>", line 671, in _load_unlocked
  File "/home/czaki/.cache/uv/.tmpYy6E4Q/.venv/lib/python3.8/site-packages/_virtualenv.py", line 91, in exec_module
    old(module)
  File "/home/czaki/.cache/uv/built-wheels-v0/pypi/setuptools/0.7.2/50gYfHetQiLPzvTHRj8sH/setuptools-0.7.2.tar.gz/setuptools/dist.py", line 103
    except ValueError, e:
                     ^
SyntaxError: invalid syntax
---                

The pyproject toml used as input is available here:
napari/napari#6673

[charliermarsh]

What version of uv are you on?

[Czaki]

uv 0.1.5

(maybe for lowest resolution it may be nice to provide barier date to not get packages older than a given date, with exception for packages that do not have newer release).

[notatallshaw]

It will be also nice to not try using python2 only packages

That's the fun thing about sdists, at least for now, you can't tell what they're compatible with until you try to build them!

[charliermarsh]

Yeah I don't think there's any way for us to know that unfortunately.

[Czaki]

Maybe you could use python classifier provided by package?

For example for setuptools 0.7.2 provides information that is compatible up to python 3.3 so maybe should not be checked for python 3.8?

[hmc-cs-mdrissi]

Python classifiers are not very useful beyond as documentation metadata the author put of we expect it to support this version. Except for many packages (especially most pure python ones), they usually support newer python versions just fine. And many packages don't have classifiers in first place. I think today classifiers do not effect resolution at all for other python resolvers, and heuristics here would likely throw out a lot of valid solutions.

[Czaki]

I do not know any python resolver that supports lowest mode. Many packages do not specify lower bound.

[konstin]

We should exempt unconstrained build dependencies from using the lowest version, otherwise we'll break everyone using a plain setuptools as build backend.

[charliermarsh]

@konstin - this must be a direct dependency, right? We don’t propagate resolution-lowest to build dependencies.

[charliermarsh]

In which case, it’s kind of… correct, to fail here? Since the markers are incorrect. The package doesn’t work with arbitrary setuptools versions.

[notatallshaw]

I assumed reading this thread that error was indeed correct, as testing the lowest resolution will mostly be revealing failing builds.

I thought the ask here from OP is that when a package build fails, to show the dependency chain of how uv got to that package, so the appropriate requirements can be added.

In general though I think users are going to find task of creating requirements that work on lowest resolution very tough, without specifying every transitive dependency. The ecosystem has never had good tooling around this, so very few maintainers add lower bound requirements unless they have a specific reason.

It depends on the motivation of the user, but it may make sense to build a lower bounds constraints file rather than an extensive requirements file.

[konstin]

this must be a direct dependency, right? We don’t propagate resolution-lowest to build dependencies.

Indeed! I think we should warn when we encounter dependencies with now lower limit and --resolution=lowest is set, hinting the user at defining a lower limit themselves.

[charliermarsh]

Closing as we've added more warnings here.