You can still `source .venv/bin/activate(.fish)` and skip the uv run bit. I have Fish shell configured to automatically activate a .venv if it finds one in a directory I switch to.
Sure thing - so I mostly ended up using this for activating a .venv in a fabfile directory using this...
function __auto_fab --on-variable PWD
iterm2_print_user_vars
if [ -d "fabfile" ]
if [ -d "fabfile/.venv" ]
if not set -q done_fab
and not set -q VIRTUAL_ENV
echo -n "Starting fabfile venv... "
pushd fabfile > /dev/null
source .venv/bin/activate.fish --prompt="[fab]"
popd > /dev/null
set -g done_fab 1
echo -e "\r Fabfile venv activated "
end
else
echo "Run gofab to create the .venv"
end
end
end
I've since deleted the one to do a .venv in this directory, but I think it was roughly this...
function __auto_venv --on-variable PWD
if [ -d ".venv" ]
if not set -q done_venv
echo -n "Starting venv... "
source .venv/bin/activate.fish --prompt="[venv]"
set -g done_venv 1
echo -e "\r Venv activated "
end
end
end
(just tested that and it seems to work - the --prompt actually gets overridden by the project name from uv's pyproject.toml now though so that's not really necessary, was useful at some point in the past)
I'm not them, but I use `direnv` for this. Their wiki includes two layout_uv[1] scripts, one that uses `uv` just to activate a regular venv and a second that uses it to manage the whole project. I use the latter.
Custom layouts are awesome. You can set up any script to run when direnv runs, so you can support just about anything you want even before direnv adds a builtin.