Usage of PYENV_DEACTIVATE?

[blueyed]

What is PYENV_DEACTIVATE useful for?
It makes you use --force to re-enable the same virtualenv again:

% pyenv activate dal
pyenv-virtualenv: activate dal
pyenv-virtualenv: prompt changing will be removed from future release. configure `export PYENV_VIRTUALENV_DISABLE_PROMPT=1' to simulate the behavior.
% pyenv deactivate dal
pyenv-virtualenv: deactivate 3.5.0/envs/dal
% pyenv activate dal
pyenv-virtualenv: `dal' is marked deactivated. use `pyenv activate --force dal' to activate forcibly.

From skimming the git log for it, it looks like it might be obsolete / not required anymore?!

[yyuu]

It is used to persist the state of manual deactivation ('pyenv deactivate') if there is pyenv-virtualenv-init is enabled.

[blueyed]

I see. But then a manual "pyenv activate" should not be blocked, right?

What about a new switch "--auto", which would be used by the automatic handler, which then would respect this var? Basically this means that --force would be used by default, but not with the automatic handler.

[yyuu]

Manual activation with pyenv virtualenv-init might be kind of a corner case. Just removing PYENV_DEACTIVATE would make implementation simpler....

[DanyC97]

So basically if i have the virtualenv-init set and still do the manual activation (say because i don't always have/ want to be ina specific dir to have it activated - i need to move around in a terminal), with the changed your pushed for review a user will have to

• in case s/he wants to take the benefit of the auto activation => must set the virtualenv_init
• in case s/he wants to take the benefit of the manual activation => must unset the virtualenv_init

Note - not place for both anymore
I understand is a bit easier from code perspective but i'd have preferred to not need to play with bashrc (add/ delete) every time i want to use one of the above options

[yyuu]

@DanyC97 So, what is your use case of manual activateion/deactivation with enabling auto-activation feature?

[DanyC97]

@yyuu so the use case (is more like how i do things) is:

• 80% of my time i use the manual activation as i'm moving around my file system and i can't be locked into a specific folder
• 20% i need to use a python package for entire work day hence what i do is to stay on 1 terminal tab in that dir which auto-activated my virtualenv and do my work.

with the current situation i don't have to fiddle with my bashrc config to add/ take out the virtualenv init part

[blueyed]

@DanyC97
I think you could still use eval "$(pyenv virtualenv-init -)", but then override / also use it manually, no? (with #123).

[yyuu]

@DanyC97
Even with this change, even if auto-activation is enabled, you can still activate a virtualenv manually if you specify version name as an argument (e.g. pyenv activate venv27 or pyenv activate 2.7.10/envs/venv27) since pyenv activate sets pyenv's shell version implicitly. You can also deactivate it manually by pyenv deactivate.

Although, you cannot do manual deactivation of global or local version since pyenv-virtualenv's hook function always tries to activate if pyenv's current version is a virtualenv. Actually, the deactivation is working. But the hook function will re-activate it just after the deactivation.

The activation in pyenv-virtualenv is now just a declaration of environment variable VIRTUAL_ENV. It will not manage PATH anymore since it is not depending on activate script of virtualenv or conda. I couldn't understand why you need manual activation/deactivation from use case you stated. If the existence of environment variable VIRTUAL_ENV is a problem, basically I'd recommend to remove eval "$(pyenv virtualenv-init -)" from his/her shell profile to disable auto-activation feature completely.... Please let me know if I missed something.

[DanyC97]

@yyuu

the manual activation i do need/ use because as i said i don't always stay on a single directory to benefit from auto-activation however when i do need it i would like to not go again and add eval "$(pyenv virtualenv-init -)" .

Most of the time i do use it with Pycharm (unfortunately it doesn't support pyenv only virtualenv) and so most of the time i manually enable so i can "view" the new interpreter in Pycharm.
Soometimes i do use it directly from terminal and as i said i move around file system where i do manually activate/ deactivate.

[blueyed]

@DanyC97
Your use case should work fine still, no?
You would only not be able to deactivate an automatically activated one (if you use virtualenv-init).

Apart from that, you might want to try https://github.com/direnv/direnv or https://github.com/Tarrasch/zsh-autoenv, which would allow you to handle it manually altogether: e.g. with zsh-autoenv, you could explicitly activate an env when entering a dir, and deactivate it when leaving (simulating what virtualenv-init provides).

[DanyC97]

@blueyed thanks for options