Support for `uv`

[zefr0x]

• I have searched the issues (including closed ones) and believe that this is not a duplicate.
• I have searched the documentation and believe that my question is not covered.
• I am willing to lend a hand to help implement this feature.
  • I don't have experience with fish scripting, but I might take a look at the code base.

Feature Request

Support for Astral.sh's new uv tool as a drop-in alternative for pip and virtualenv commands.

[justinmayer]

What is the rationale for this proposal? What problems would it solve?

[zefr0x]

What is the rationale for this proposal? What problems would it solve?

1. If I'm using uv it wouldn't make scene to have python-virtualenv and other utilities that provide the same functionality in my system.

2. uv will make most tasks blazingly faster for people who want to use it, since it was written in lower level language with best practices and doesn't have the limitations of current tools. (Benchmarks: https://github.com/astral-sh/uv/blob/main/BENCHMARKS.md)

---

The only disadvantage that I can see is that uv might not support every thing used in virtualfish, but we need to take a look at virtualfish's code base first.

[justinmayer]

If someone would like to propose a uv-related PR in a way that notably improves VirtualFish, I would be happy to merge it.

I am not much interested in purity. Respectfully, I believe that terms like “lower level” and “best practices” are largely subjective and unrelated to providing good end-user experiences.

As it relates to speed, the provided benchmarks link talks about dependency resolution, which is only related to VirtualFish by way of its use of Pip to install packages. As far as virtual environments, virtual environment creation is faster in uv but not in a way that is noticeable to end users — both uv and Virtualenv create environments in milliseconds. Virtual environment activation speeds are comparable, in the single-digit milliseconds for each.

Perhaps new environment variable setting(s) could be added that allow the user to choose which tool(s) to use for (1) virtual environment creation and (2) package installation. Something like:

set -gx VIRTUALFISH_VENV_TOOL "virtualenv"  # Or "uv", etc.
set -gx VIRTUALFISH_PACKAGE_TOOL "pip"    # Or "uv", etc.

Ideally such a change would be implemented in the form of a plugin, if technically feasible.

[icezyclon]

What is the rationale for this proposal? What problems would it solve?

I would argue that the power of uv is in its project handling capabilities, specifically the pyproject.toml and uv.lock files, which are not in the virtualenv itself!
You don't get the abilities to uv sync and uv lock by simply running uv in an existing virtualenv created by a different tool (even though you can with uv pip install --python /path/to/python or just setting VIRTUAL_ENV).
Also, using uv just to create the virtualenv (apart from a very minor speedup) is not really the reason why I would want to use uv in the first place.
I feel that this is out-of-scope for virtualfish and should probably be handled on the uv side instead.

---

Therefore, I wrote an opinionated fisher plugin using both uv and virtualfish that also create a uv-project in addition to the environment.
Aside from vf new (replaced by mkuvenv) it is fully compatible with virtualfish and allows me to keep my virtualfish workflow that I am used to 👍 .

[zefr0x]

https://github.com/zefr0x/dotfiles/blob/73df3f3cfe33d23dfb37d5f2645675ab2c5f15c8/utils/fish/functions/vf.fish

[icezyclon]

https://github.com/zefr0x/dotfiles/blob/73df3f3cfe33d23dfb37d5f2645675ab2c5f15c8/utils/fish/functions/vf.fish

Nice, but as far as I see it's missing what I think makes uv so "powerful": the project files as explained above (so uv sync, uv lock, uv tree and so on).
I think this is just a difference in opinion what the focus of using uv should be 👍