Summary
In Fedora, we are generally uncomfortable with programs installing software from outside of Fedora without the user explicitly requesting it. (Programs that are only useful after downloading external code are actually prohibited in Fedora.)
In our uv package, these considerations have lead us to ship an /etc/uv/uv.toml that sets python-downloads = "manual" and python-preference = "system" for Fedora-packaged uv. This has worked quite satisfactorily, and it seems to be working well enough for our users.
From the same perspective, the new experimental uv format command is a bit concerning for distribution packaging, since its default behavior is to download and execute a pre-compiled binary of a particular version of ruff, and since I suspect many users will not be aware that this is what is happening. I think that the uv format --version=x.y.z case is not too worrisome, because the user is explicitly requesting a particular version of ruff (and we obviously don’t have a variety of system-wide ruff versions to choose from).
Obviously, it would be best if the ruff for uv format could instead be our own system ruff package. However, it’s not reasonably possible, or even necessarily desirable, for us to keep our ruff aligned to the version that’s the default for uv format in the version of uv shipped in each branch. Both packages are nontrivial to maintain (considering their large dependency trees) and have different primary downstream maintainers and current downstream update cadences. Tying them together would not only require even more disciplined and coordinated maintenance, but it would also mean both packages had to be blocked on each other’s dependencies. Besides, we may have other reasons to update one package ahead of the other. I don’t think letting uv format control the version of ruff in Fedora would be successful in the long run.
I don’t think we would be wise to patch uv to use a the system ruff regardless of version, either: the ruff version guarantee (and therefore the guarantee of stable/predictable default formatting behavior for a particular uv version) is designed into the uv format interface. If Fedora’s uv format produced different formatted code for a particular uv release than a pip-installed copy of the same uv release, or if the results of uv format changed without updating uv because ruff was updated separately, it seems like that would be a big enough divergence from the upstream behavior that it could be an ugly surprise for users.
What remains, as suggested by @hroncok, is that perhaps there could be a configuration option in uv.toml to change the behavior such that, when uv format needs to install the default ruff version, it complains something like “uv format needs ruff 1.2.3.4; use uv format --download-ruff to get it” and exits with a nonzero code. What do you think? Is this a viable avenue? Do you have any alternative ideas for how we could ensure that users of Fedora’s uv package don’t end up installing non-Fedora binaries by accident?
(Mentioning @decathorpe, who may also be interested in this.)
Example
No response
Summary
In Fedora, we are generally uncomfortable with programs installing software from outside of Fedora without the user explicitly requesting it. (Programs that are only useful after downloading external code are actually prohibited in Fedora.)
In our
uvpackage, these considerations have lead us to ship an/etc/uv/uv.tomlthat setspython-downloads = "manual"andpython-preference = "system"for Fedora-packageduv. This has worked quite satisfactorily, and it seems to be working well enough for our users.From the same perspective, the new experimental
uv formatcommand is a bit concerning for distribution packaging, since its default behavior is to download and execute a pre-compiled binary of a particular version ofruff, and since I suspect many users will not be aware that this is what is happening. I think that theuv format --version=x.y.zcase is not too worrisome, because the user is explicitly requesting a particular version ofruff(and we obviously don’t have a variety of system-wideruffversions to choose from).Obviously, it would be best if the
ruffforuv formatcould instead be our own systemruffpackage. However, it’s not reasonably possible, or even necessarily desirable, for us to keep ourruffaligned to the version that’s the default foruv formatin the version ofuvshipped in each branch. Both packages are nontrivial to maintain (considering their large dependency trees) and have different primary downstream maintainers and current downstream update cadences. Tying them together would not only require even more disciplined and coordinated maintenance, but it would also mean both packages had to be blocked on each other’s dependencies. Besides, we may have other reasons to update one package ahead of the other. I don’t think lettinguv formatcontrol the version ofruffin Fedora would be successful in the long run.I don’t think we would be wise to patch
uvto use a the systemruffregardless of version, either: theruffversion guarantee (and therefore the guarantee of stable/predictable default formatting behavior for a particularuvversion) is designed into theuv formatinterface. If Fedora’suv formatproduced different formatted code for a particularuvrelease than a pip-installed copy of the sameuvrelease, or if the results ofuv formatchanged without updatinguvbecauseruffwas updated separately, it seems like that would be a big enough divergence from the upstream behavior that it could be an ugly surprise for users.What remains, as suggested by @hroncok, is that perhaps there could be a configuration option in
uv.tomlto change the behavior such that, whenuv formatneeds to install the defaultruffversion, it complains something like “uv format needs ruff 1.2.3.4; use uv format --download-ruff to get it” and exits with a nonzero code. What do you think? Is this a viable avenue? Do you have any alternative ideas for how we could ensure that users of Fedora’suvpackage don’t end up installing non-Fedora binaries by accident?(Mentioning @decathorpe, who may also be interested in this.)
Example
No response