Could there be an alias for `deactivate` e.g., `workoff`?
PinkShnack opened this issue · comments
As far as I can see from the repo, virtualenvwrapper-win does not provide its own deactivate.bat batch file. This means that when I run deactivate, my machine defaults to the conda deactivate command by using the deactivate file. This (I assume) can happen to others whose base python installation came with the Anaconda or Miniconda distribution. It also means that I cannot deactivate my virtualenvwrapper environment, I can only swap between them.
I currently workaround this by creating a copy of the deactivate file and calling it deactivate.bat. Now virtualenvwrapper will correctly point to this file and deactivate the virtualenvwrapper environment.
Is it possible for there to be an alias for deactivate for virtualenvwrapper-win such as workoff, or even include a deactivate.bat file by that name?
Please let me know if I am doing something wrong and if the above is possible.
Python via Minconda: 3.9.1
I don't use conda, so I don't know how it installs itself. virtualenvwrapper-win uses the activate.bat/deactivate.bat files that virtualenv puts in the created venv's scripts folder. If you look at activate.bat, it prepends the scripts folder to the path, so (unless you've done something weird) the scripts\deactivate.bat should always be found first.
virtualenvwrapper-win comes with a whereis command that can tell you which file it finds first on the path (i.e. try running whereis deactivate).
For my case anyway, this scripts folder is the same location as the Miniconda scripts folder. All of the other virtualenvwrapper command-files (eg add2virtualenv.bat, whereis.bat etc) are also there, so I assume this is where deactivate.bat should have been placed.
Does this mean that virtualenvwrapper tried to create a deactivate.bat file but couldn't because of the conda file of the same name that was already present? Have you ever heard of this happening? Is it even a thing that could happen?
I don't use (mini)conda, so I don't know how it installs itself. I'm assuming that if two different packages tries to install a file with the same name then one of them will "win" - and the other "lose". It is the virtualenv package that installs activate/deactivate.bat for virtualenvwrapper-win and I haven't checked what their installer does if it finds an existing miniconda deactivate.bat file. Might be best not to mix virtualenv managers in the same virtualenv..?
It might make sense to add an extra option to workon.bat. E.g. workon --stop or workon --deactivate.
workon exit will work (assuming you don't have a virtualenv named exit, since the first action workon does is to deactivate the current virtualenv. You'll get som warning messages about the exit virtualenv not existing though...
I like that... workon nothing ;-)