You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
When I am using zsh and 'initialize' mise (eval "$(mise activate zsh)") whenever I cd in or out of a folder with a .mise.toml or .tools-version file my $VIRTUAL_ENV varible is removed. It happens even on the 'eval' command as well.
source any virtualenvironment source path/to/venv/bin/activate
echo $VIRTUAL_ENV
path/to/venv
either have mise activated and be in a folder with the given .mise.toml: cd .. echo $VIRTUAL_ENV
``
or run: eval "$(mise activate zsh)" echo $VIRTUAL_ENV
``
while when I do cd .. - now I am in a folder without .mise.toml source path/to/venv/bin/activate echo $VIRTUAL_ENV
path/to/venv
cd .. - again a folder without .mise.toml echo $VIRTUAL_ENV
path/to/venv
A more detailed dump of me exploring is on the bottom.
Expected behavior
If not configured to automatically 'activate' or 'deactivate' virtual environments in 'python' to not touch the environment variable.
I guess $PATH modification in both cases is to be expected, as this is what 'mise' does when not using 'shims', maybe though, the modification should take into account if $VIRTUAL_ENV is set? (But I guess that would be more a feature request than this bug report?).
Maybe this is also intended behaviour, to not confuse having $VIRTUAL_ENV set, but pointing with $PATH to another python-interpreter?
The current behaviour definitely avoids somewhat problems for this case and if a the prompt shows the current virtual env by using the variable, at least one sees it immediately.
I would expect to still keep my sourced virtual env active, when traversing the file system.
Additional context
I tried it with an older version, there was the same behavior, then I updated mise and the behavior was still the same.
For comparison I started a bash to see if things are different there, and they are.
I tried with both .tools-versions and .mise.toml as config files locally.
Here a dump from my environment, with some censoring
mise was not initialized in this shell, to show it better:
# no mise initialized
❯ echo$PATH
/home/*****/.cache/antidote/https-COLON--SLASH--SLASH-github.51.al-SLASH-romkatv-SLASH-zsh-bench:/home/*****/.nix-profile/bin:/nix/var/nix/profiles/default/bin:/home/linuxbrew/.linuxbrew/bin:/home/*****/.local/share/go/bin:/home/*****/.local/share/cargo/bin:/usr/local:/home/*****/.poetry/bin:/home/*****/.local/bin:/home/*****/bin:/usr/local/bin:/usr/local/sbin:/usr/sbin:/sbin:/home/linuxbrew/.linuxbrew/bin:/home/linuxbrew/.linuxbrew/sbin:/home/*****/.rye/shims:/home/*****/.cargo/bin:/home/*****/.local/bin:/home/*****/.nix-profile/bin:/nix/var/nix/profiles/default/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games:/usr/local/games:/snap/bin:/snap/bin:/bin:/home/*****/.fzf/bin
❯ which python
/home/*****/.rye/shims/python
# here I have ryes python version
❯ z html
# I jump into my project~/path/to/****/libraries/my-project ****-***
❯ ls .mise.toml
.mise.toml
~/path/to/****/libraries/my-project ****-***
❯ source /home/*****/.local/share/virtualenvs/my-project/bin/activate
~/path/to/****/libraries/my-project ****-***
❯ which python
/home/*****/.local/share/virtualenvs/my-project/bin/python
# Now we have my venvs python~/path/to/****/libraries/my-project ****-***
❯ echo$PATH
/home/*****/.local/share/virtualenvs/my-project/bin:/home/*****/.cache/antidote/https-COLON--SLASH--SLASH-github.51.al-SLASH-romkatv-SLASH-zsh-bench:/home/*****/.nix-profile/bin:/nix/var/nix/profiles/default/bin:/home/linuxbrew/.linuxbrew/bin:/home/*****/.local/share/go/bin:/home/*****/.local/share/cargo/bin:/usr/local:/home/*****/.poetry/bin:/home/*****/.local/bin:/home/*****/bin:/usr/local/bin:/usr/local/sbin:/usr/sbin:/sbin:/home/linuxbrew/.linuxbrew/bin:/home/linuxbrew/.linuxbrew/sbin:/home/*****/.rye/shims:/home/*****/.cargo/bin:/home/*****/.local/bin:/home/*****/.nix-profile/bin:/nix/var/nix/profiles/default/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games:/usr/local/games:/snap/bin:/snap/bin:/bin:/home/*****/.fzf/bin
~/path/to/****/libraries/my-project ****-***
❯ echo$VIRTUAL_ENV
/home/*****/.local/share/virtualenvs/my-project
# The venv works~/path/to/****/libraries/my-project ****-***
❯ cd ..
~/path/to/****/libraries
❯ ls .mise.toml
ls: cannot access '.mise.toml': No such file or directory
~/path/to/****/libraries
❯ echo$VIRTUAL_ENV
/home/*****/.local/share/virtualenvs/my-project
# Nothing changed by changing dir ~/path/to/****/libraries
❯ eval"$(mise activate zsh)"# Mise is activated~/path/to/****/libraries
❯ echo$VIRTUAL_ENV# My venv is deleted~/path/to/****/libraries
❯ echo$PATH
/home/*****/.local/share/mise/installs/python/3.10/bin:/home/*****/.local/share/mise/installs/python/3.9/bin:/home/*****/.local/share/mise/installs/python/3.11/bin:/home/*****/.local/share/mise/installs/python/3.12/bin:/home/*****/.local/share/mise/installs/poetry/1.6.1/bin:/home/*****/.local/share/mise/installs/java/adoptopenjdk-11.0.16+8/bin:/home/*****/.local/share/virtualenvs/my-project/bin:/home/*****/.cache/antidote/https-COLON--SLASH--SLASH-github.51.al-SLASH-romkatv-SLASH-zsh-bench:/home/*****/.nix-profile/bin:/nix/var/nix/profiles/default/bin:/home/linuxbrew/.linuxbrew/bin:/home/*****/.local/share/go/bin:/home/*****/.local/share/cargo/bin:/usr/local:/home/*****/.poetry/bin:/home/*****/.local/bin:/home/*****/bin:/usr/local/bin:/usr/local/sbin:/usr/sbin:/sbin:/home/linuxbrew/.linuxbrew/bin:/home/linuxbrew/.linuxbrew/sbin:/home/*****/.rye/shims:/home/*****/.cargo/bin:/home/*****/.local/bin:/home/*****/.nix-profile/bin:/nix/var/nix/profiles/default/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games:/usr/local/games:/snap/bin:/snap/bin:/bin:/home/*****/.fzf/bin
# My path is changed~/path/to/****/libraries
❯ source /home/*****/.local/share/virtualenvs/my-project/bin/activate
# I activate my venv again~/path/to/****/libraries
❯ echo$VIRTUAL_ENV
/home/*****/.local/share/virtualenvs/my-project
~/path/to/****/libraries
❯ cd -
~/path/to/****/libraries/my-project
~/path/to/****/libraries/my-project ****-***
❯ echo$VIRTUAL_ENV# After changing dir, my virtual env is modified~/path/to/****/libraries/my-project ****-***
❮ cd ..
~/path/to/****/libraries
❯ ls .mise.toml
ls: cannot access '.mise.toml': No such file or directory
# now I am in a folder with no mise config file~/path/to/****/libraries
❯ source /home/*****/.local/share/virtualenvs/my-project/bin/activate
~/path/to/****/libraries
❯ echo$VIRTUAL_ENV
/home/*****/.local/share/virtualenvs/my-project
~/path/to/****/libraries
❮ cd ..
~/path/to/****
❯ ls .mise.toml
ls: cannot access '.mise.toml': No such file or directory
~/path/to/****
❯ echo$VIRTUAL_ENV
/home/*****/.local/share/virtualenvs/my-project
# Traversing the filesystem in between folders with no mise config file does not break venv
The text was updated successfully, but these errors were encountered:
Describe the bug
When I am using
zsh
and 'initialize' mise (eval "$(mise activate zsh)"
) whenever Icd
in or out of a folder with a.mise.toml
or.tools-version
file my$VIRTUAL_ENV
varible is removed. It happens even on the 'eval' command as well.I tried it with
bash
too, seems to do the same.To Reproduce
my config files:
.mise.toml
~/.config/mise/config.toml
source any virtualenvironment
source path/to/venv/bin/activate
echo $VIRTUAL_ENV
either have mise activated and be in a folder with the given
.mise.toml
:cd ..
echo $VIRTUAL_ENV
or run:
eval "$(mise activate zsh)"
echo $VIRTUAL_ENV
while when I do
cd ..
- now I am in a folder without.mise.toml
source path/to/venv/bin/activate
echo $VIRTUAL_ENV
cd ..
- again a folder without.mise.toml
echo $VIRTUAL_ENV
A more detailed dump of me exploring is on the bottom.
Expected behavior
If not configured to automatically 'activate' or 'deactivate' virtual environments in 'python' to not touch the environment variable.
I guess
$PATH
modification in both cases is to be expected, as this is what 'mise' does when not using 'shims', maybe though, the modification should take into account if$VIRTUAL_ENV
is set? (But I guess that would be more a feature request than this bug report?).Maybe this is also intended behaviour, to not confuse having
$VIRTUAL_ENV
set, but pointing with$PATH
to another python-interpreter?The current behaviour definitely avoids somewhat problems for this case and if a the prompt shows the current virtual env by using the variable, at least one sees it immediately.
I would expect to still keep my sourced virtual env active, when traversing the file system.
mise doctor
outputAdditional context
I tried it with an older version, there was the same behavior, then I updated
mise
and the behavior was still the same.For comparison I started a
bash
to see if things are different there, and they are.I tried with both
.tools-versions
and.mise.toml
as config files locally.Here a dump from my environment, with some censoring
mise was not initialized in this shell, to show it better:
The text was updated successfully, but these errors were encountered: