1. Doug Hellmann
  2. virtualenvwrapper
  3. Pull requests

Pull requests

#3 Declined

Ignore deactivate output silencing a possible anaconda deactivate script.

  1. Fredrik Hedman

With anaconda in the path it has its own deactivate which demands to be sourced. When executed it outputs an "Error".

Silencing this error seems to be ok, since the horkon function then goes on to do the right thing and also create its own deactivate.

Comments (1)

  1. Fredrik Hedman author

    Thank for a swift comment. I can certainly submit upstream. Sorry for that.

    This seems to be a case of namespace collisions. If you happen to use the anaconda distribution you will have a deactivate script in your path and if you start from a fresh shell and run mkvirtualenv or workon there will be a surprising error because the anaconda deactivate script expects to be sourced. It gives the impression something is wrong. Reading the code and the comments the intention seems to "destructively" deactivate so it is like a "--force" operation. As is it is now I get erroneous instructions from another tool...for example:

    $ source activate py1yr
    discarding /Users/hedman/tmp/anaconda3/bin from PATH
    prepending /Users/hedman/tmp/anaconda3/envs/py1yr/bin to PATH
    (py1yr)$ source deactivate 
    discarding /Users/hedman/tmp/anaconda3/envs/py1yr/bin from PATH
    $ workon tutorial1
    Error: deactivate must be sourced. Run 'source deactivate'
    instead of 'deactivate'.
    Usage: source deactivate
    removes the 'bin' directory of the environment activated with 'source
    activate' from PATH. 
    (tutorial1)$ deactivate 

    For sure cond env and virtualenv do not coexist prectly, but this fix would decrease the sonfusion;)