astral-sh / uv

An extremely fast Python package and project manager, written in Rust.
https://docs.astral.sh/uv
Apache License 2.0
25.54k stars 743 forks source link

Configure pip compile via pyproject.toml or uv.toml #3883

Open inoa-jboliveira opened 5 months ago

inoa-jboliveira commented 5 months ago

Recently uv started supporting TOML config files and it has been very useful. I believe it could be greatly expanded. (BTW, there is no "discussions" page on this Github project. I would prefer posting it there instead of an issue).

Currently pip-tools is configurable via pyproject.toml , so I believe we could have very similar configs for the high level options like generate_hashes and annotate.

The reason I opened this discussion is to go even further and solve a problem I always had with pip-tools.

My project has multiple .in files and multiple .txt outputs. Each in file has windows and linux versions and we will start having them for multiple python versions to be able to support Python 3.12 and 3.13 where it is hard to find compatible libs that still support 3.9 simultaneously.

Our current approach is to have a script like this:

uv pip compile ./requirements/requirements.in ./requirements/requirements-dev.in -o ./requirements/requirements-dev-linux.txt --python-platform=linux
uv pip compile ./requirements/requirements.in -o ./requirements/requirements-linux.txt --python-platform=linux
uv pip compile ./requirements/requirements.in ./requirements/requirements-dev.in -o ./requirements/requirements-dev-win.txt --python-platform=windows
uv pip compile ./requirements/requirements.in -o ./requirements/requirements-win.txt --python-platform=windows

But if I want, lets say, upgrade a lib, I have to pass extra parameters to all these commands. So in fact I never use uv pip compile but a wrapper around it.

It would be way better if I had a pyproject.toml like this:

[tool.uv.pip.compile.outputs]
foo-win.txt = { in = foo.in, python-platform = windows }
foo-linux.txt = { in = foo.in, python-platform = linux }
bar-py39.txt = { in = bar.in, python-version = 3.9 }
bar-py312.txt = { in = bar.in, python-version = 3.12 }

Then I would just run uv pip compile and it would generate all files. Better yet, if I did uv pip compile --upgrade numpy it would also pass this parameter to all the files.

inoa-jboliveira commented 1 month ago

Hi everyone, I feel like uv lock is way more versatile and my worflow no longer contains pip compile but it does have multiple uv export which guarantee versions are the same across multiple txt files. Also I adopted the universal format long ago which greatly simplified the workflow even with pip compile.

From my end, this PR can be closed. I let the maintainer decide since there are some thumbs up emojis

ssbarnea commented 18 hours ago

I don't think this should be closed because current behavior can cause some nasty bugs, basically if someone tries to configure --python-version=3.10 for compile, they will break their uv usage in other places. [tool.uv.pip] is not appropriate for use, clearly we need a [tool.uv.pip.compile] for putting specific options there.

Note that uv.lock file is not supported by dependabot and is highly unlikely that it will become supported in the next few years.

How to fully break uv:

[tool.uv.pip]
annotation-style = "line"
custom-compile-command = "tox run deps"
python-version = "3.10" # <-- that will cause it to install wrong wheels

The last line makes uv install the wrong wheel, even if documentation states that it should do something different:

 --python-version <PYTHON_VERSION>      The minimum Python version that should be supported by the requirements (e.g., `3.7` or `3.7.9`)

I tried to use this config option in order to produce predictable lock file using uv pip compile but the side effect is that once you configure it, uv will start installing wrong binary wheel all the time.

zanieb commented 10 hours ago

I think we should be able to improve the behavior you've described there.

Note that uv.lock file is not supported by dependabot and is highly unlikely that it will become supported in the next few years.

A bit of an aside, but it's a pity to see how slow support is moving over there. It's worth noting that Renovate does support uv.lock already.