Regression on lockfile gen with uv resolver where ...
# development
b
Regression on lockfile gen with uv resolver where pex works I hit an issue where the
uv
resolver fails. It's a weird situation, but one pex/pip handles without issue. • For <reasons> we have a python library called
dd-internal-pyspark
that depends directly on a wheel URL, where the URL has some version info in it • The
python_requirements
target points to dependencies in a pyproject.toml with
dd-internal-pyspark
and
url/to/wheel/at-{specific-version}
. • pex/pip resolution finds the version of
dd-internal-pyspark
that depends on the same wheel URL as the pyproject.toml dep. uv picks a version of
dd-internal-pyspark
that is too new and depends on the wrong wheel URL. I know this is kind of weird for most people. I also only just started looking into it and haven't investigated, but I wanted to report the issue right away
uv fail
Copy code
% pants --python-resolver=uv generate-lockfiles --resolve=example
09:36:22.55 [INFO] Completed: Generate uv lockfile for example
09:36:22.56 [ERROR] 1 Exception encountered:

Engine traceback:
  in `generate-lockfiles` goal

ProcessExecutionFailure: Process 'Generate uv lockfile for example' failed with exit code 1.
stdout:

stderr:
Using CPython 3.12.8
  × Failed to resolve dependencies for `dd-internal-pyspark` (v2.4.5)
  ╰─▶ Requirements contain conflicting URLs for package `balto` in all marker
      environments:
      - <https://binaries.ddbuild.io/dd-source/python/balto-0.0.109945538-py3-none-any.whl>
  help: `dd-internal-pyspark` (v2.4.5) was included because
        `pants-lockfile-for-example` (v0.0.0) depends on
        `dd-internal-pyspark>=2.0, <3.dev0`


Use `--keep-sandboxes=on_failure` to preserve the process chroot for inspection.
pex success
Copy code
% pants --python-resolver=pex generate-lockfiles --resolve=example
09:38:20.82 [INFO] Completed: Generate pex lockfile for example
09:38:20.83 [INFO] Wrote lockfile for the resolve `example` to subprojects/example/3rdparty/python/lockfile.json

Lockfile diff: subprojects/example/3rdparty/python/lockfile.json [example]

==                    Upgraded dependencies                     ==

  importlib-metadata             8.7.1        -->   9.0.0
  numpy                          2.4.5        -->   2.4.6
  opentelemetry-api              1.41.1       -->   1.42.0
This is probably more about
uv
limitations than anything
pants
is doing
w
Yeah it's possible pex accidentally worked before in this case. Would probably need to dig a bit on what the exact error is and then reference python/PEP expectations.
h
Can you reproduce this with
uv
outside of Pants? One way is to run with
--keep-sandboxes=on_failure
and then grab the uv cmd out of the sandbox (it's in
__run.sh
) and see if you can tinker with it.
b
yeah, I'm reproducing it with
uv
now. I probably need to tinker with the pyproject.toml more