How to leave/exit/deactivate a python virtualenv?












1215















I'm using virtualenv and the virtualenvwrapper. I can switch between virtualenv's just fine using the workon command.



me@mymachine:~$ workon env1
(env1)me@mymachine:~$ workon env2
(env2)me@mymachine:~$ workon env1
(env1)me@mymachine:~$


However, how do I exit all virtual machines and workon my real machine again? Right now, the only way I have of getting back to



me@mymachine:~$ 


is to exit the shell and start a new one. That's kind of annoying. Is there a command to workon "nothing", and if so, what is it? If such a command does not exist, how would I go about creating it?










share|improve this question




















  • 4





    There is a command to workon "nothing" - it displays all your available virtual environments, which is pretty nifty. Just type "workon" with no arguments and hit enter. The command to leave is "deactivate", as answered below.

    – Dannid
    Oct 7 '14 at 20:47
















1215















I'm using virtualenv and the virtualenvwrapper. I can switch between virtualenv's just fine using the workon command.



me@mymachine:~$ workon env1
(env1)me@mymachine:~$ workon env2
(env2)me@mymachine:~$ workon env1
(env1)me@mymachine:~$


However, how do I exit all virtual machines and workon my real machine again? Right now, the only way I have of getting back to



me@mymachine:~$ 


is to exit the shell and start a new one. That's kind of annoying. Is there a command to workon "nothing", and if so, what is it? If such a command does not exist, how would I go about creating it?










share|improve this question




















  • 4





    There is a command to workon "nothing" - it displays all your available virtual environments, which is pretty nifty. Just type "workon" with no arguments and hit enter. The command to leave is "deactivate", as answered below.

    – Dannid
    Oct 7 '14 at 20:47














1215












1215








1215


214






I'm using virtualenv and the virtualenvwrapper. I can switch between virtualenv's just fine using the workon command.



me@mymachine:~$ workon env1
(env1)me@mymachine:~$ workon env2
(env2)me@mymachine:~$ workon env1
(env1)me@mymachine:~$


However, how do I exit all virtual machines and workon my real machine again? Right now, the only way I have of getting back to



me@mymachine:~$ 


is to exit the shell and start a new one. That's kind of annoying. Is there a command to workon "nothing", and if so, what is it? If such a command does not exist, how would I go about creating it?










share|improve this question
















I'm using virtualenv and the virtualenvwrapper. I can switch between virtualenv's just fine using the workon command.



me@mymachine:~$ workon env1
(env1)me@mymachine:~$ workon env2
(env2)me@mymachine:~$ workon env1
(env1)me@mymachine:~$


However, how do I exit all virtual machines and workon my real machine again? Right now, the only way I have of getting back to



me@mymachine:~$ 


is to exit the shell and start a new one. That's kind of annoying. Is there a command to workon "nothing", and if so, what is it? If such a command does not exist, how would I go about creating it?







python virtualenv virtualenvwrapper






share|improve this question















share|improve this question













share|improve this question




share|improve this question








edited Aug 31 '16 at 16:42









nobar

26.2k108599




26.2k108599










asked Jun 13 '09 at 14:15









AprecheApreche

9,16383444




9,16383444








  • 4





    There is a command to workon "nothing" - it displays all your available virtual environments, which is pretty nifty. Just type "workon" with no arguments and hit enter. The command to leave is "deactivate", as answered below.

    – Dannid
    Oct 7 '14 at 20:47














  • 4





    There is a command to workon "nothing" - it displays all your available virtual environments, which is pretty nifty. Just type "workon" with no arguments and hit enter. The command to leave is "deactivate", as answered below.

    – Dannid
    Oct 7 '14 at 20:47








4




4





There is a command to workon "nothing" - it displays all your available virtual environments, which is pretty nifty. Just type "workon" with no arguments and hit enter. The command to leave is "deactivate", as answered below.

– Dannid
Oct 7 '14 at 20:47





There is a command to workon "nothing" - it displays all your available virtual environments, which is pretty nifty. Just type "workon" with no arguments and hit enter. The command to leave is "deactivate", as answered below.

– Dannid
Oct 7 '14 at 20:47












8 Answers
8






active

oldest

votes


















1983














Usually, activating a virtualenv gives you a shell function named:



$ deactivate


which puts things back to normal.



Edit 1



I have just looked specifically again at the code for virtualenvwrapper, and, yes, it too supports deactivate as the way to escape from all virtualenvs.



Edit 2



If you are trying to leave an Anaconda environment, the procedure is a bit different: run the two-word command source deactivate since they implement deactivation using a stand-alone script.



bash-4.3$ deactivate
pyenv-virtualenv: deactivate must be sourced. Run 'source deactivate' instead of 'deactivate'
bash-4.3$ source deactivate
pyenv-virtualenv: no virtualenv has been activated.





share|improve this answer





















  • 6





    My virtualenv has no deactivate command

    – Prof. Falken
    Feb 6 '13 at 16:44






  • 88





    The “deactivate” command is not a binary, nor a script that you “source”; it is a shell alias that gets defined dynamically in your current shell by the “activate” script.

    – Brandon Rhodes
    Feb 6 '13 at 22:28






  • 6





    @Apreche In the meantime (almost four years later) this appears to have been added to the documentation.

    – gertvdijk
    Mar 14 '13 at 14:26






  • 6





    Would be much more intuitive if it were called "workoff" or "unworkon". Or if "workon" were called "activate". Thank goodness for alias.

    – kkurian
    Jun 18 '13 at 17:54






  • 13





    Guess what the actual virtualenv command inside of "workon" is called? ...(spoiler warning)... ...(spoiler warning)... ...(spoiler warning)... ...(spoiler warning)... activate!

    – FutureNerd
    Mar 20 '14 at 5:18





















36














I defined an alias workoff as the opposite of workon:



alias workoff='deactivate'


Easy to remember:



[bobstein@host ~]$ workon django_project
(django_project)[bobstein@host ~]$ workoff
[bobstein@host ~]$





share|improve this answer


























  • In which file? .bashrc?

    – seyed
    Jun 8 '15 at 17:59











  • @seyed yes, see this answer for an example of alias in ~/.bashrc

    – Bob Stein
    Jun 8 '15 at 19:37






  • 16





    I like this alias. Reminds me of the Karate Kid (waxon; waxoff)

    – C0deH4cker
    Oct 2 '16 at 1:59











  • Awesome ! I really like this ;)

    – Yasser Sinjab
    Mar 1 '17 at 13:33



















30














$ deactivate 


If this doesn't work , try



$ source deactivate


Anyone who knows how bash source works will think that's odd, but some wrappers/workflows around virtualenv implement as a compliment/counterpart to source activate. YMMV






share|improve this answer





















  • 3





    deactivate is a function that gets created when you source the activate file. Your suggestion to do source deactivate doesn't make sense at all, as there is no file named deactivate

    – Anthon
    Apr 12 '15 at 8:14








  • 6





    This doesn't deserve the downvotes. See edit of selected response: source deactivate is for the anaconda environment.

    – Doug Bradshaw
    Nov 13 '15 at 19:52






  • 2





    It "deserves" downvotes for not meeting the SO answer quality standards. It's more of a comment than an answer. But, because of the 79 reputation of the poster, we should be nice and give good feedback.

    – Bruno Bronosky
    Mar 17 '17 at 15:22











  • @Abdul I have demonstrated how you can improve your answer quality in Revision 2 at stackoverflow.com/posts/29586756/revisions

    – Bruno Bronosky
    Mar 17 '17 at 15:30











  • this is very unhelpful if you don't have a deactivate command in your shell. I don't really understand why this would help the problem. There is no deactivate script in the virtual env.

    – bgenchel
    Feb 28 '18 at 6:26



















10














to activate python virtual environment:



$cd ~/python-venv/
$./bin/activate


to deactivate:



$deactivate





share|improve this answer



















  • 3





    In terminal on OS X10.11.1, I seem to have to use: $source activate

    – Eric Milliot-Martinez
    Dec 5 '15 at 19:15













  • I didn't need source. I did $cd /to/dir/i/want/my/virtualenv/installed then $virtualenv name_i_want_for_it then $. name_i_want_for_it/bin/activate virtualenv still seems a bit off to me. Needs to be improved...

    – uchuugaka
    Dec 28 '15 at 8:32






  • 2





    "source" is the same as the "." command.. either can be used to source a file

    – Corey Goldberg
    Jan 10 '17 at 18:12



















2














You can use virtualenvwrapper in order to ease the way you work with virtualenv



Installing virtualenvwrapper



pip install virtualenvwrapper


If you are using standard shell, open your ~/.bashrc or ~/.zshrc if you use oh-my-zsh. Add this two lines:



export WORKON_HOME=$HOME/.virtualenvs  
source /usr/local/bin/virtualenvwrapper.sh


To activate an existing virtualenv, use command workon:



$ workon myenv
(myenv)$


In order to deactivate your virtualenv:



(myenv)$ deactivate


Here is my tutorial, step by step in how to install virtualenv and virtualenvwrapper






share|improve this answer



















  • 1





    I see little difference compared to built-in virtualenv

    – Nam G VU
    Sep 8 '16 at 11:35






  • 1





    @NamGVU Notice the workon command, it works from any directory.

    – igaurav
    Sep 28 '16 at 7:44











  • OP is already using virtualenvwrapper, no?

    – Radon Rosborough
    Jan 9 '18 at 21:40











  • Does not work really. deactivate: command not found.

    – Schütze
    Mar 27 '18 at 8:17





















0














I use zsh-autoenv which is based off autoenv.




zsh-autoenv automatically
sources (known/whitelisted) .autoenv.zsh files, typically used in
project root directories. It handles "enter" and leave" events,
nesting, and stashing of variables (overwriting and restoring).




Here is an example:



; cd dtree 
Switching to virtual environment: Development tree utiles
;dtree(feature/task24|✓); cat .autoenv.zsh
# Autoenv.
echo -n "Switching to virtual environment: "
printf "e[38;5;93m%se[0mn" "Development tree utiles"
workon dtree
# eof
dtree(feature/task24|✓); cat .autoenv_leave.zsh
deactivate


So when I leave the dtree directory, the virtual environment is automatically exited.






share|improve this answer































    0














    (my_env) basant@basant:~/EonTraining/my_env$ deactivate



    use 'deactivate'



    basant@basant-Lenovo-E40-80:~/EonTraining/my_env$



    Gone (my_env);






    share|improve this answer































      -1














      Had the same problem myself while working on an installer script, I took a look at what the bin/activate_this.py did and reversed it.



      Example:



      #! /usr/bin/python
      # -*- coding: utf-8 -*-
      import os
      import sys

      # path to virtualenv
      venv_path = os.path.join('/home', 'sixdays', '.virtualenvs', 'test32')

      # Save old values
      old_os_path = os.environ['PATH']
      old_sys_path = list(sys.path)
      old_sys_prefix = sys.prefix


      def deactivate():
      # Change back by setting values to starting values
      os.environ['PATH'] = old_os_path
      sys.prefix = old_sys_prefix
      sys.path[:0] = old_sys_path


      # Activate the virtualenvironment
      activate_this = os.path.join(venv_path, 'bin/activate_this.py')
      execfile(activate_this, dict(__file__=activate_this))


      # Print list of pip packages for virtualenv for example purpose
      import pip
      print str(pip.get_installed_distributions())
      # Unload pip module
      del pip

      # deactive/switch back to initial interpreter
      deactivate()

      # print list of initial environment pip packages for example purpose
      import pip
      print str(pip.get_installed_distributions())


      Not 100% sure if it works as intended, I may have missed something completely.






      share|improve this answer



















      • 1





        if deactivate resets value of environment path, system path, default prompt then your deactivate function is good approach. I like your script. Already given +1.

        – Ramkumar D
        Jun 6 '16 at 8:00










      protected by dano May 6 '15 at 17:59



      Thank you for your interest in this question.
      Because it has attracted low-quality or spam answers that had to be removed, posting an answer now requires 10 reputation on this site (the association bonus does not count).



      Would you like to answer one of these unanswered questions instead?














      8 Answers
      8






      active

      oldest

      votes








      8 Answers
      8






      active

      oldest

      votes









      active

      oldest

      votes






      active

      oldest

      votes









      1983














      Usually, activating a virtualenv gives you a shell function named:



      $ deactivate


      which puts things back to normal.



      Edit 1



      I have just looked specifically again at the code for virtualenvwrapper, and, yes, it too supports deactivate as the way to escape from all virtualenvs.



      Edit 2



      If you are trying to leave an Anaconda environment, the procedure is a bit different: run the two-word command source deactivate since they implement deactivation using a stand-alone script.



      bash-4.3$ deactivate
      pyenv-virtualenv: deactivate must be sourced. Run 'source deactivate' instead of 'deactivate'
      bash-4.3$ source deactivate
      pyenv-virtualenv: no virtualenv has been activated.





      share|improve this answer





















      • 6





        My virtualenv has no deactivate command

        – Prof. Falken
        Feb 6 '13 at 16:44






      • 88





        The “deactivate” command is not a binary, nor a script that you “source”; it is a shell alias that gets defined dynamically in your current shell by the “activate” script.

        – Brandon Rhodes
        Feb 6 '13 at 22:28






      • 6





        @Apreche In the meantime (almost four years later) this appears to have been added to the documentation.

        – gertvdijk
        Mar 14 '13 at 14:26






      • 6





        Would be much more intuitive if it were called "workoff" or "unworkon". Or if "workon" were called "activate". Thank goodness for alias.

        – kkurian
        Jun 18 '13 at 17:54






      • 13





        Guess what the actual virtualenv command inside of "workon" is called? ...(spoiler warning)... ...(spoiler warning)... ...(spoiler warning)... ...(spoiler warning)... activate!

        – FutureNerd
        Mar 20 '14 at 5:18


















      1983














      Usually, activating a virtualenv gives you a shell function named:



      $ deactivate


      which puts things back to normal.



      Edit 1



      I have just looked specifically again at the code for virtualenvwrapper, and, yes, it too supports deactivate as the way to escape from all virtualenvs.



      Edit 2



      If you are trying to leave an Anaconda environment, the procedure is a bit different: run the two-word command source deactivate since they implement deactivation using a stand-alone script.



      bash-4.3$ deactivate
      pyenv-virtualenv: deactivate must be sourced. Run 'source deactivate' instead of 'deactivate'
      bash-4.3$ source deactivate
      pyenv-virtualenv: no virtualenv has been activated.





      share|improve this answer





















      • 6





        My virtualenv has no deactivate command

        – Prof. Falken
        Feb 6 '13 at 16:44






      • 88





        The “deactivate” command is not a binary, nor a script that you “source”; it is a shell alias that gets defined dynamically in your current shell by the “activate” script.

        – Brandon Rhodes
        Feb 6 '13 at 22:28






      • 6





        @Apreche In the meantime (almost four years later) this appears to have been added to the documentation.

        – gertvdijk
        Mar 14 '13 at 14:26






      • 6





        Would be much more intuitive if it were called "workoff" or "unworkon". Or if "workon" were called "activate". Thank goodness for alias.

        – kkurian
        Jun 18 '13 at 17:54






      • 13





        Guess what the actual virtualenv command inside of "workon" is called? ...(spoiler warning)... ...(spoiler warning)... ...(spoiler warning)... ...(spoiler warning)... activate!

        – FutureNerd
        Mar 20 '14 at 5:18
















      1983












      1983








      1983







      Usually, activating a virtualenv gives you a shell function named:



      $ deactivate


      which puts things back to normal.



      Edit 1



      I have just looked specifically again at the code for virtualenvwrapper, and, yes, it too supports deactivate as the way to escape from all virtualenvs.



      Edit 2



      If you are trying to leave an Anaconda environment, the procedure is a bit different: run the two-word command source deactivate since they implement deactivation using a stand-alone script.



      bash-4.3$ deactivate
      pyenv-virtualenv: deactivate must be sourced. Run 'source deactivate' instead of 'deactivate'
      bash-4.3$ source deactivate
      pyenv-virtualenv: no virtualenv has been activated.





      share|improve this answer















      Usually, activating a virtualenv gives you a shell function named:



      $ deactivate


      which puts things back to normal.



      Edit 1



      I have just looked specifically again at the code for virtualenvwrapper, and, yes, it too supports deactivate as the way to escape from all virtualenvs.



      Edit 2



      If you are trying to leave an Anaconda environment, the procedure is a bit different: run the two-word command source deactivate since they implement deactivation using a stand-alone script.



      bash-4.3$ deactivate
      pyenv-virtualenv: deactivate must be sourced. Run 'source deactivate' instead of 'deactivate'
      bash-4.3$ source deactivate
      pyenv-virtualenv: no virtualenv has been activated.






      share|improve this answer














      share|improve this answer



      share|improve this answer








      edited Mar 29 '17 at 13:51









      nbro

      5,65384995




      5,65384995










      answered Jun 13 '09 at 14:31









      Brandon RhodesBrandon Rhodes

      52.3k1392128




      52.3k1392128








      • 6





        My virtualenv has no deactivate command

        – Prof. Falken
        Feb 6 '13 at 16:44






      • 88





        The “deactivate” command is not a binary, nor a script that you “source”; it is a shell alias that gets defined dynamically in your current shell by the “activate” script.

        – Brandon Rhodes
        Feb 6 '13 at 22:28






      • 6





        @Apreche In the meantime (almost four years later) this appears to have been added to the documentation.

        – gertvdijk
        Mar 14 '13 at 14:26






      • 6





        Would be much more intuitive if it were called "workoff" or "unworkon". Or if "workon" were called "activate". Thank goodness for alias.

        – kkurian
        Jun 18 '13 at 17:54






      • 13





        Guess what the actual virtualenv command inside of "workon" is called? ...(spoiler warning)... ...(spoiler warning)... ...(spoiler warning)... ...(spoiler warning)... activate!

        – FutureNerd
        Mar 20 '14 at 5:18
















      • 6





        My virtualenv has no deactivate command

        – Prof. Falken
        Feb 6 '13 at 16:44






      • 88





        The “deactivate” command is not a binary, nor a script that you “source”; it is a shell alias that gets defined dynamically in your current shell by the “activate” script.

        – Brandon Rhodes
        Feb 6 '13 at 22:28






      • 6





        @Apreche In the meantime (almost four years later) this appears to have been added to the documentation.

        – gertvdijk
        Mar 14 '13 at 14:26






      • 6





        Would be much more intuitive if it were called "workoff" or "unworkon". Or if "workon" were called "activate". Thank goodness for alias.

        – kkurian
        Jun 18 '13 at 17:54






      • 13





        Guess what the actual virtualenv command inside of "workon" is called? ...(spoiler warning)... ...(spoiler warning)... ...(spoiler warning)... ...(spoiler warning)... activate!

        – FutureNerd
        Mar 20 '14 at 5:18










      6




      6





      My virtualenv has no deactivate command

      – Prof. Falken
      Feb 6 '13 at 16:44





      My virtualenv has no deactivate command

      – Prof. Falken
      Feb 6 '13 at 16:44




      88




      88





      The “deactivate” command is not a binary, nor a script that you “source”; it is a shell alias that gets defined dynamically in your current shell by the “activate” script.

      – Brandon Rhodes
      Feb 6 '13 at 22:28





      The “deactivate” command is not a binary, nor a script that you “source”; it is a shell alias that gets defined dynamically in your current shell by the “activate” script.

      – Brandon Rhodes
      Feb 6 '13 at 22:28




      6




      6





      @Apreche In the meantime (almost four years later) this appears to have been added to the documentation.

      – gertvdijk
      Mar 14 '13 at 14:26





      @Apreche In the meantime (almost four years later) this appears to have been added to the documentation.

      – gertvdijk
      Mar 14 '13 at 14:26




      6




      6





      Would be much more intuitive if it were called "workoff" or "unworkon". Or if "workon" were called "activate". Thank goodness for alias.

      – kkurian
      Jun 18 '13 at 17:54





      Would be much more intuitive if it were called "workoff" or "unworkon". Or if "workon" were called "activate". Thank goodness for alias.

      – kkurian
      Jun 18 '13 at 17:54




      13




      13





      Guess what the actual virtualenv command inside of "workon" is called? ...(spoiler warning)... ...(spoiler warning)... ...(spoiler warning)... ...(spoiler warning)... activate!

      – FutureNerd
      Mar 20 '14 at 5:18







      Guess what the actual virtualenv command inside of "workon" is called? ...(spoiler warning)... ...(spoiler warning)... ...(spoiler warning)... ...(spoiler warning)... activate!

      – FutureNerd
      Mar 20 '14 at 5:18















      36














      I defined an alias workoff as the opposite of workon:



      alias workoff='deactivate'


      Easy to remember:



      [bobstein@host ~]$ workon django_project
      (django_project)[bobstein@host ~]$ workoff
      [bobstein@host ~]$





      share|improve this answer


























      • In which file? .bashrc?

        – seyed
        Jun 8 '15 at 17:59











      • @seyed yes, see this answer for an example of alias in ~/.bashrc

        – Bob Stein
        Jun 8 '15 at 19:37






      • 16





        I like this alias. Reminds me of the Karate Kid (waxon; waxoff)

        – C0deH4cker
        Oct 2 '16 at 1:59











      • Awesome ! I really like this ;)

        – Yasser Sinjab
        Mar 1 '17 at 13:33
















      36














      I defined an alias workoff as the opposite of workon:



      alias workoff='deactivate'


      Easy to remember:



      [bobstein@host ~]$ workon django_project
      (django_project)[bobstein@host ~]$ workoff
      [bobstein@host ~]$





      share|improve this answer


























      • In which file? .bashrc?

        – seyed
        Jun 8 '15 at 17:59











      • @seyed yes, see this answer for an example of alias in ~/.bashrc

        – Bob Stein
        Jun 8 '15 at 19:37






      • 16





        I like this alias. Reminds me of the Karate Kid (waxon; waxoff)

        – C0deH4cker
        Oct 2 '16 at 1:59











      • Awesome ! I really like this ;)

        – Yasser Sinjab
        Mar 1 '17 at 13:33














      36












      36








      36







      I defined an alias workoff as the opposite of workon:



      alias workoff='deactivate'


      Easy to remember:



      [bobstein@host ~]$ workon django_project
      (django_project)[bobstein@host ~]$ workoff
      [bobstein@host ~]$





      share|improve this answer















      I defined an alias workoff as the opposite of workon:



      alias workoff='deactivate'


      Easy to remember:



      [bobstein@host ~]$ workon django_project
      (django_project)[bobstein@host ~]$ workoff
      [bobstein@host ~]$






      share|improve this answer














      share|improve this answer



      share|improve this answer








      edited Apr 13 '17 at 12:22









      Community

      11




      11










      answered Jan 14 '15 at 16:23









      Bob SteinBob Stein

      7,14135174




      7,14135174













      • In which file? .bashrc?

        – seyed
        Jun 8 '15 at 17:59











      • @seyed yes, see this answer for an example of alias in ~/.bashrc

        – Bob Stein
        Jun 8 '15 at 19:37






      • 16





        I like this alias. Reminds me of the Karate Kid (waxon; waxoff)

        – C0deH4cker
        Oct 2 '16 at 1:59











      • Awesome ! I really like this ;)

        – Yasser Sinjab
        Mar 1 '17 at 13:33



















      • In which file? .bashrc?

        – seyed
        Jun 8 '15 at 17:59











      • @seyed yes, see this answer for an example of alias in ~/.bashrc

        – Bob Stein
        Jun 8 '15 at 19:37






      • 16





        I like this alias. Reminds me of the Karate Kid (waxon; waxoff)

        – C0deH4cker
        Oct 2 '16 at 1:59











      • Awesome ! I really like this ;)

        – Yasser Sinjab
        Mar 1 '17 at 13:33

















      In which file? .bashrc?

      – seyed
      Jun 8 '15 at 17:59





      In which file? .bashrc?

      – seyed
      Jun 8 '15 at 17:59













      @seyed yes, see this answer for an example of alias in ~/.bashrc

      – Bob Stein
      Jun 8 '15 at 19:37





      @seyed yes, see this answer for an example of alias in ~/.bashrc

      – Bob Stein
      Jun 8 '15 at 19:37




      16




      16





      I like this alias. Reminds me of the Karate Kid (waxon; waxoff)

      – C0deH4cker
      Oct 2 '16 at 1:59





      I like this alias. Reminds me of the Karate Kid (waxon; waxoff)

      – C0deH4cker
      Oct 2 '16 at 1:59













      Awesome ! I really like this ;)

      – Yasser Sinjab
      Mar 1 '17 at 13:33





      Awesome ! I really like this ;)

      – Yasser Sinjab
      Mar 1 '17 at 13:33











      30














      $ deactivate 


      If this doesn't work , try



      $ source deactivate


      Anyone who knows how bash source works will think that's odd, but some wrappers/workflows around virtualenv implement as a compliment/counterpart to source activate. YMMV






      share|improve this answer





















      • 3





        deactivate is a function that gets created when you source the activate file. Your suggestion to do source deactivate doesn't make sense at all, as there is no file named deactivate

        – Anthon
        Apr 12 '15 at 8:14








      • 6





        This doesn't deserve the downvotes. See edit of selected response: source deactivate is for the anaconda environment.

        – Doug Bradshaw
        Nov 13 '15 at 19:52






      • 2





        It "deserves" downvotes for not meeting the SO answer quality standards. It's more of a comment than an answer. But, because of the 79 reputation of the poster, we should be nice and give good feedback.

        – Bruno Bronosky
        Mar 17 '17 at 15:22











      • @Abdul I have demonstrated how you can improve your answer quality in Revision 2 at stackoverflow.com/posts/29586756/revisions

        – Bruno Bronosky
        Mar 17 '17 at 15:30











      • this is very unhelpful if you don't have a deactivate command in your shell. I don't really understand why this would help the problem. There is no deactivate script in the virtual env.

        – bgenchel
        Feb 28 '18 at 6:26
















      30














      $ deactivate 


      If this doesn't work , try



      $ source deactivate


      Anyone who knows how bash source works will think that's odd, but some wrappers/workflows around virtualenv implement as a compliment/counterpart to source activate. YMMV






      share|improve this answer





















      • 3





        deactivate is a function that gets created when you source the activate file. Your suggestion to do source deactivate doesn't make sense at all, as there is no file named deactivate

        – Anthon
        Apr 12 '15 at 8:14








      • 6





        This doesn't deserve the downvotes. See edit of selected response: source deactivate is for the anaconda environment.

        – Doug Bradshaw
        Nov 13 '15 at 19:52






      • 2





        It "deserves" downvotes for not meeting the SO answer quality standards. It's more of a comment than an answer. But, because of the 79 reputation of the poster, we should be nice and give good feedback.

        – Bruno Bronosky
        Mar 17 '17 at 15:22











      • @Abdul I have demonstrated how you can improve your answer quality in Revision 2 at stackoverflow.com/posts/29586756/revisions

        – Bruno Bronosky
        Mar 17 '17 at 15:30











      • this is very unhelpful if you don't have a deactivate command in your shell. I don't really understand why this would help the problem. There is no deactivate script in the virtual env.

        – bgenchel
        Feb 28 '18 at 6:26














      30












      30








      30







      $ deactivate 


      If this doesn't work , try



      $ source deactivate


      Anyone who knows how bash source works will think that's odd, but some wrappers/workflows around virtualenv implement as a compliment/counterpart to source activate. YMMV






      share|improve this answer















      $ deactivate 


      If this doesn't work , try



      $ source deactivate


      Anyone who knows how bash source works will think that's odd, but some wrappers/workflows around virtualenv implement as a compliment/counterpart to source activate. YMMV







      share|improve this answer














      share|improve this answer



      share|improve this answer








      edited Mar 17 '17 at 15:27









      Bruno Bronosky

      34.7k47984




      34.7k47984










      answered Apr 12 '15 at 6:41









      DarkRiderDarkRider

      33934




      33934








      • 3





        deactivate is a function that gets created when you source the activate file. Your suggestion to do source deactivate doesn't make sense at all, as there is no file named deactivate

        – Anthon
        Apr 12 '15 at 8:14








      • 6





        This doesn't deserve the downvotes. See edit of selected response: source deactivate is for the anaconda environment.

        – Doug Bradshaw
        Nov 13 '15 at 19:52






      • 2





        It "deserves" downvotes for not meeting the SO answer quality standards. It's more of a comment than an answer. But, because of the 79 reputation of the poster, we should be nice and give good feedback.

        – Bruno Bronosky
        Mar 17 '17 at 15:22











      • @Abdul I have demonstrated how you can improve your answer quality in Revision 2 at stackoverflow.com/posts/29586756/revisions

        – Bruno Bronosky
        Mar 17 '17 at 15:30











      • this is very unhelpful if you don't have a deactivate command in your shell. I don't really understand why this would help the problem. There is no deactivate script in the virtual env.

        – bgenchel
        Feb 28 '18 at 6:26














      • 3





        deactivate is a function that gets created when you source the activate file. Your suggestion to do source deactivate doesn't make sense at all, as there is no file named deactivate

        – Anthon
        Apr 12 '15 at 8:14








      • 6





        This doesn't deserve the downvotes. See edit of selected response: source deactivate is for the anaconda environment.

        – Doug Bradshaw
        Nov 13 '15 at 19:52






      • 2





        It "deserves" downvotes for not meeting the SO answer quality standards. It's more of a comment than an answer. But, because of the 79 reputation of the poster, we should be nice and give good feedback.

        – Bruno Bronosky
        Mar 17 '17 at 15:22











      • @Abdul I have demonstrated how you can improve your answer quality in Revision 2 at stackoverflow.com/posts/29586756/revisions

        – Bruno Bronosky
        Mar 17 '17 at 15:30











      • this is very unhelpful if you don't have a deactivate command in your shell. I don't really understand why this would help the problem. There is no deactivate script in the virtual env.

        – bgenchel
        Feb 28 '18 at 6:26








      3




      3





      deactivate is a function that gets created when you source the activate file. Your suggestion to do source deactivate doesn't make sense at all, as there is no file named deactivate

      – Anthon
      Apr 12 '15 at 8:14







      deactivate is a function that gets created when you source the activate file. Your suggestion to do source deactivate doesn't make sense at all, as there is no file named deactivate

      – Anthon
      Apr 12 '15 at 8:14






      6




      6





      This doesn't deserve the downvotes. See edit of selected response: source deactivate is for the anaconda environment.

      – Doug Bradshaw
      Nov 13 '15 at 19:52





      This doesn't deserve the downvotes. See edit of selected response: source deactivate is for the anaconda environment.

      – Doug Bradshaw
      Nov 13 '15 at 19:52




      2




      2





      It "deserves" downvotes for not meeting the SO answer quality standards. It's more of a comment than an answer. But, because of the 79 reputation of the poster, we should be nice and give good feedback.

      – Bruno Bronosky
      Mar 17 '17 at 15:22





      It "deserves" downvotes for not meeting the SO answer quality standards. It's more of a comment than an answer. But, because of the 79 reputation of the poster, we should be nice and give good feedback.

      – Bruno Bronosky
      Mar 17 '17 at 15:22













      @Abdul I have demonstrated how you can improve your answer quality in Revision 2 at stackoverflow.com/posts/29586756/revisions

      – Bruno Bronosky
      Mar 17 '17 at 15:30





      @Abdul I have demonstrated how you can improve your answer quality in Revision 2 at stackoverflow.com/posts/29586756/revisions

      – Bruno Bronosky
      Mar 17 '17 at 15:30













      this is very unhelpful if you don't have a deactivate command in your shell. I don't really understand why this would help the problem. There is no deactivate script in the virtual env.

      – bgenchel
      Feb 28 '18 at 6:26





      this is very unhelpful if you don't have a deactivate command in your shell. I don't really understand why this would help the problem. There is no deactivate script in the virtual env.

      – bgenchel
      Feb 28 '18 at 6:26











      10














      to activate python virtual environment:



      $cd ~/python-venv/
      $./bin/activate


      to deactivate:



      $deactivate





      share|improve this answer



















      • 3





        In terminal on OS X10.11.1, I seem to have to use: $source activate

        – Eric Milliot-Martinez
        Dec 5 '15 at 19:15













      • I didn't need source. I did $cd /to/dir/i/want/my/virtualenv/installed then $virtualenv name_i_want_for_it then $. name_i_want_for_it/bin/activate virtualenv still seems a bit off to me. Needs to be improved...

        – uchuugaka
        Dec 28 '15 at 8:32






      • 2





        "source" is the same as the "." command.. either can be used to source a file

        – Corey Goldberg
        Jan 10 '17 at 18:12
















      10














      to activate python virtual environment:



      $cd ~/python-venv/
      $./bin/activate


      to deactivate:



      $deactivate





      share|improve this answer



















      • 3





        In terminal on OS X10.11.1, I seem to have to use: $source activate

        – Eric Milliot-Martinez
        Dec 5 '15 at 19:15













      • I didn't need source. I did $cd /to/dir/i/want/my/virtualenv/installed then $virtualenv name_i_want_for_it then $. name_i_want_for_it/bin/activate virtualenv still seems a bit off to me. Needs to be improved...

        – uchuugaka
        Dec 28 '15 at 8:32






      • 2





        "source" is the same as the "." command.. either can be used to source a file

        – Corey Goldberg
        Jan 10 '17 at 18:12














      10












      10








      10







      to activate python virtual environment:



      $cd ~/python-venv/
      $./bin/activate


      to deactivate:



      $deactivate





      share|improve this answer













      to activate python virtual environment:



      $cd ~/python-venv/
      $./bin/activate


      to deactivate:



      $deactivate






      share|improve this answer












      share|improve this answer



      share|improve this answer










      answered Nov 26 '15 at 7:06









      Amitesh RanjanAmitesh Ranjan

      551179




      551179








      • 3





        In terminal on OS X10.11.1, I seem to have to use: $source activate

        – Eric Milliot-Martinez
        Dec 5 '15 at 19:15













      • I didn't need source. I did $cd /to/dir/i/want/my/virtualenv/installed then $virtualenv name_i_want_for_it then $. name_i_want_for_it/bin/activate virtualenv still seems a bit off to me. Needs to be improved...

        – uchuugaka
        Dec 28 '15 at 8:32






      • 2





        "source" is the same as the "." command.. either can be used to source a file

        – Corey Goldberg
        Jan 10 '17 at 18:12














      • 3





        In terminal on OS X10.11.1, I seem to have to use: $source activate

        – Eric Milliot-Martinez
        Dec 5 '15 at 19:15













      • I didn't need source. I did $cd /to/dir/i/want/my/virtualenv/installed then $virtualenv name_i_want_for_it then $. name_i_want_for_it/bin/activate virtualenv still seems a bit off to me. Needs to be improved...

        – uchuugaka
        Dec 28 '15 at 8:32






      • 2





        "source" is the same as the "." command.. either can be used to source a file

        – Corey Goldberg
        Jan 10 '17 at 18:12








      3




      3





      In terminal on OS X10.11.1, I seem to have to use: $source activate

      – Eric Milliot-Martinez
      Dec 5 '15 at 19:15







      In terminal on OS X10.11.1, I seem to have to use: $source activate

      – Eric Milliot-Martinez
      Dec 5 '15 at 19:15















      I didn't need source. I did $cd /to/dir/i/want/my/virtualenv/installed then $virtualenv name_i_want_for_it then $. name_i_want_for_it/bin/activate virtualenv still seems a bit off to me. Needs to be improved...

      – uchuugaka
      Dec 28 '15 at 8:32





      I didn't need source. I did $cd /to/dir/i/want/my/virtualenv/installed then $virtualenv name_i_want_for_it then $. name_i_want_for_it/bin/activate virtualenv still seems a bit off to me. Needs to be improved...

      – uchuugaka
      Dec 28 '15 at 8:32




      2




      2





      "source" is the same as the "." command.. either can be used to source a file

      – Corey Goldberg
      Jan 10 '17 at 18:12





      "source" is the same as the "." command.. either can be used to source a file

      – Corey Goldberg
      Jan 10 '17 at 18:12











      2














      You can use virtualenvwrapper in order to ease the way you work with virtualenv



      Installing virtualenvwrapper



      pip install virtualenvwrapper


      If you are using standard shell, open your ~/.bashrc or ~/.zshrc if you use oh-my-zsh. Add this two lines:



      export WORKON_HOME=$HOME/.virtualenvs  
      source /usr/local/bin/virtualenvwrapper.sh


      To activate an existing virtualenv, use command workon:



      $ workon myenv
      (myenv)$


      In order to deactivate your virtualenv:



      (myenv)$ deactivate


      Here is my tutorial, step by step in how to install virtualenv and virtualenvwrapper






      share|improve this answer



















      • 1





        I see little difference compared to built-in virtualenv

        – Nam G VU
        Sep 8 '16 at 11:35






      • 1





        @NamGVU Notice the workon command, it works from any directory.

        – igaurav
        Sep 28 '16 at 7:44











      • OP is already using virtualenvwrapper, no?

        – Radon Rosborough
        Jan 9 '18 at 21:40











      • Does not work really. deactivate: command not found.

        – Schütze
        Mar 27 '18 at 8:17


















      2














      You can use virtualenvwrapper in order to ease the way you work with virtualenv



      Installing virtualenvwrapper



      pip install virtualenvwrapper


      If you are using standard shell, open your ~/.bashrc or ~/.zshrc if you use oh-my-zsh. Add this two lines:



      export WORKON_HOME=$HOME/.virtualenvs  
      source /usr/local/bin/virtualenvwrapper.sh


      To activate an existing virtualenv, use command workon:



      $ workon myenv
      (myenv)$


      In order to deactivate your virtualenv:



      (myenv)$ deactivate


      Here is my tutorial, step by step in how to install virtualenv and virtualenvwrapper






      share|improve this answer



















      • 1





        I see little difference compared to built-in virtualenv

        – Nam G VU
        Sep 8 '16 at 11:35






      • 1





        @NamGVU Notice the workon command, it works from any directory.

        – igaurav
        Sep 28 '16 at 7:44











      • OP is already using virtualenvwrapper, no?

        – Radon Rosborough
        Jan 9 '18 at 21:40











      • Does not work really. deactivate: command not found.

        – Schütze
        Mar 27 '18 at 8:17
















      2












      2








      2







      You can use virtualenvwrapper in order to ease the way you work with virtualenv



      Installing virtualenvwrapper



      pip install virtualenvwrapper


      If you are using standard shell, open your ~/.bashrc or ~/.zshrc if you use oh-my-zsh. Add this two lines:



      export WORKON_HOME=$HOME/.virtualenvs  
      source /usr/local/bin/virtualenvwrapper.sh


      To activate an existing virtualenv, use command workon:



      $ workon myenv
      (myenv)$


      In order to deactivate your virtualenv:



      (myenv)$ deactivate


      Here is my tutorial, step by step in how to install virtualenv and virtualenvwrapper






      share|improve this answer













      You can use virtualenvwrapper in order to ease the way you work with virtualenv



      Installing virtualenvwrapper



      pip install virtualenvwrapper


      If you are using standard shell, open your ~/.bashrc or ~/.zshrc if you use oh-my-zsh. Add this two lines:



      export WORKON_HOME=$HOME/.virtualenvs  
      source /usr/local/bin/virtualenvwrapper.sh


      To activate an existing virtualenv, use command workon:



      $ workon myenv
      (myenv)$


      In order to deactivate your virtualenv:



      (myenv)$ deactivate


      Here is my tutorial, step by step in how to install virtualenv and virtualenvwrapper







      share|improve this answer












      share|improve this answer



      share|improve this answer










      answered Sep 1 '16 at 5:13









      levilevi

      14.2k24553




      14.2k24553








      • 1





        I see little difference compared to built-in virtualenv

        – Nam G VU
        Sep 8 '16 at 11:35






      • 1





        @NamGVU Notice the workon command, it works from any directory.

        – igaurav
        Sep 28 '16 at 7:44











      • OP is already using virtualenvwrapper, no?

        – Radon Rosborough
        Jan 9 '18 at 21:40











      • Does not work really. deactivate: command not found.

        – Schütze
        Mar 27 '18 at 8:17
















      • 1





        I see little difference compared to built-in virtualenv

        – Nam G VU
        Sep 8 '16 at 11:35






      • 1





        @NamGVU Notice the workon command, it works from any directory.

        – igaurav
        Sep 28 '16 at 7:44











      • OP is already using virtualenvwrapper, no?

        – Radon Rosborough
        Jan 9 '18 at 21:40











      • Does not work really. deactivate: command not found.

        – Schütze
        Mar 27 '18 at 8:17










      1




      1





      I see little difference compared to built-in virtualenv

      – Nam G VU
      Sep 8 '16 at 11:35





      I see little difference compared to built-in virtualenv

      – Nam G VU
      Sep 8 '16 at 11:35




      1




      1





      @NamGVU Notice the workon command, it works from any directory.

      – igaurav
      Sep 28 '16 at 7:44





      @NamGVU Notice the workon command, it works from any directory.

      – igaurav
      Sep 28 '16 at 7:44













      OP is already using virtualenvwrapper, no?

      – Radon Rosborough
      Jan 9 '18 at 21:40





      OP is already using virtualenvwrapper, no?

      – Radon Rosborough
      Jan 9 '18 at 21:40













      Does not work really. deactivate: command not found.

      – Schütze
      Mar 27 '18 at 8:17







      Does not work really. deactivate: command not found.

      – Schütze
      Mar 27 '18 at 8:17













      0














      I use zsh-autoenv which is based off autoenv.




      zsh-autoenv automatically
      sources (known/whitelisted) .autoenv.zsh files, typically used in
      project root directories. It handles "enter" and leave" events,
      nesting, and stashing of variables (overwriting and restoring).




      Here is an example:



      ; cd dtree 
      Switching to virtual environment: Development tree utiles
      ;dtree(feature/task24|✓); cat .autoenv.zsh
      # Autoenv.
      echo -n "Switching to virtual environment: "
      printf "e[38;5;93m%se[0mn" "Development tree utiles"
      workon dtree
      # eof
      dtree(feature/task24|✓); cat .autoenv_leave.zsh
      deactivate


      So when I leave the dtree directory, the virtual environment is automatically exited.






      share|improve this answer




























        0














        I use zsh-autoenv which is based off autoenv.




        zsh-autoenv automatically
        sources (known/whitelisted) .autoenv.zsh files, typically used in
        project root directories. It handles "enter" and leave" events,
        nesting, and stashing of variables (overwriting and restoring).




        Here is an example:



        ; cd dtree 
        Switching to virtual environment: Development tree utiles
        ;dtree(feature/task24|✓); cat .autoenv.zsh
        # Autoenv.
        echo -n "Switching to virtual environment: "
        printf "e[38;5;93m%se[0mn" "Development tree utiles"
        workon dtree
        # eof
        dtree(feature/task24|✓); cat .autoenv_leave.zsh
        deactivate


        So when I leave the dtree directory, the virtual environment is automatically exited.






        share|improve this answer


























          0












          0








          0







          I use zsh-autoenv which is based off autoenv.




          zsh-autoenv automatically
          sources (known/whitelisted) .autoenv.zsh files, typically used in
          project root directories. It handles "enter" and leave" events,
          nesting, and stashing of variables (overwriting and restoring).




          Here is an example:



          ; cd dtree 
          Switching to virtual environment: Development tree utiles
          ;dtree(feature/task24|✓); cat .autoenv.zsh
          # Autoenv.
          echo -n "Switching to virtual environment: "
          printf "e[38;5;93m%se[0mn" "Development tree utiles"
          workon dtree
          # eof
          dtree(feature/task24|✓); cat .autoenv_leave.zsh
          deactivate


          So when I leave the dtree directory, the virtual environment is automatically exited.






          share|improve this answer













          I use zsh-autoenv which is based off autoenv.




          zsh-autoenv automatically
          sources (known/whitelisted) .autoenv.zsh files, typically used in
          project root directories. It handles "enter" and leave" events,
          nesting, and stashing of variables (overwriting and restoring).




          Here is an example:



          ; cd dtree 
          Switching to virtual environment: Development tree utiles
          ;dtree(feature/task24|✓); cat .autoenv.zsh
          # Autoenv.
          echo -n "Switching to virtual environment: "
          printf "e[38;5;93m%se[0mn" "Development tree utiles"
          workon dtree
          # eof
          dtree(feature/task24|✓); cat .autoenv_leave.zsh
          deactivate


          So when I leave the dtree directory, the virtual environment is automatically exited.







          share|improve this answer












          share|improve this answer



          share|improve this answer










          answered Feb 14 '17 at 10:50









          SardathrionSardathrion

          6,146136099




          6,146136099























              0














              (my_env) basant@basant:~/EonTraining/my_env$ deactivate



              use 'deactivate'



              basant@basant-Lenovo-E40-80:~/EonTraining/my_env$



              Gone (my_env);






              share|improve this answer




























                0














                (my_env) basant@basant:~/EonTraining/my_env$ deactivate



                use 'deactivate'



                basant@basant-Lenovo-E40-80:~/EonTraining/my_env$



                Gone (my_env);






                share|improve this answer


























                  0












                  0








                  0







                  (my_env) basant@basant:~/EonTraining/my_env$ deactivate



                  use 'deactivate'



                  basant@basant-Lenovo-E40-80:~/EonTraining/my_env$



                  Gone (my_env);






                  share|improve this answer













                  (my_env) basant@basant:~/EonTraining/my_env$ deactivate



                  use 'deactivate'



                  basant@basant-Lenovo-E40-80:~/EonTraining/my_env$



                  Gone (my_env);







                  share|improve this answer












                  share|improve this answer



                  share|improve this answer










                  answered Sep 3 '17 at 6:43









                  Basant RulesBasant Rules

                  45148




                  45148























                      -1














                      Had the same problem myself while working on an installer script, I took a look at what the bin/activate_this.py did and reversed it.



                      Example:



                      #! /usr/bin/python
                      # -*- coding: utf-8 -*-
                      import os
                      import sys

                      # path to virtualenv
                      venv_path = os.path.join('/home', 'sixdays', '.virtualenvs', 'test32')

                      # Save old values
                      old_os_path = os.environ['PATH']
                      old_sys_path = list(sys.path)
                      old_sys_prefix = sys.prefix


                      def deactivate():
                      # Change back by setting values to starting values
                      os.environ['PATH'] = old_os_path
                      sys.prefix = old_sys_prefix
                      sys.path[:0] = old_sys_path


                      # Activate the virtualenvironment
                      activate_this = os.path.join(venv_path, 'bin/activate_this.py')
                      execfile(activate_this, dict(__file__=activate_this))


                      # Print list of pip packages for virtualenv for example purpose
                      import pip
                      print str(pip.get_installed_distributions())
                      # Unload pip module
                      del pip

                      # deactive/switch back to initial interpreter
                      deactivate()

                      # print list of initial environment pip packages for example purpose
                      import pip
                      print str(pip.get_installed_distributions())


                      Not 100% sure if it works as intended, I may have missed something completely.






                      share|improve this answer



















                      • 1





                        if deactivate resets value of environment path, system path, default prompt then your deactivate function is good approach. I like your script. Already given +1.

                        – Ramkumar D
                        Jun 6 '16 at 8:00
















                      -1














                      Had the same problem myself while working on an installer script, I took a look at what the bin/activate_this.py did and reversed it.



                      Example:



                      #! /usr/bin/python
                      # -*- coding: utf-8 -*-
                      import os
                      import sys

                      # path to virtualenv
                      venv_path = os.path.join('/home', 'sixdays', '.virtualenvs', 'test32')

                      # Save old values
                      old_os_path = os.environ['PATH']
                      old_sys_path = list(sys.path)
                      old_sys_prefix = sys.prefix


                      def deactivate():
                      # Change back by setting values to starting values
                      os.environ['PATH'] = old_os_path
                      sys.prefix = old_sys_prefix
                      sys.path[:0] = old_sys_path


                      # Activate the virtualenvironment
                      activate_this = os.path.join(venv_path, 'bin/activate_this.py')
                      execfile(activate_this, dict(__file__=activate_this))


                      # Print list of pip packages for virtualenv for example purpose
                      import pip
                      print str(pip.get_installed_distributions())
                      # Unload pip module
                      del pip

                      # deactive/switch back to initial interpreter
                      deactivate()

                      # print list of initial environment pip packages for example purpose
                      import pip
                      print str(pip.get_installed_distributions())


                      Not 100% sure if it works as intended, I may have missed something completely.






                      share|improve this answer



















                      • 1





                        if deactivate resets value of environment path, system path, default prompt then your deactivate function is good approach. I like your script. Already given +1.

                        – Ramkumar D
                        Jun 6 '16 at 8:00














                      -1












                      -1








                      -1







                      Had the same problem myself while working on an installer script, I took a look at what the bin/activate_this.py did and reversed it.



                      Example:



                      #! /usr/bin/python
                      # -*- coding: utf-8 -*-
                      import os
                      import sys

                      # path to virtualenv
                      venv_path = os.path.join('/home', 'sixdays', '.virtualenvs', 'test32')

                      # Save old values
                      old_os_path = os.environ['PATH']
                      old_sys_path = list(sys.path)
                      old_sys_prefix = sys.prefix


                      def deactivate():
                      # Change back by setting values to starting values
                      os.environ['PATH'] = old_os_path
                      sys.prefix = old_sys_prefix
                      sys.path[:0] = old_sys_path


                      # Activate the virtualenvironment
                      activate_this = os.path.join(venv_path, 'bin/activate_this.py')
                      execfile(activate_this, dict(__file__=activate_this))


                      # Print list of pip packages for virtualenv for example purpose
                      import pip
                      print str(pip.get_installed_distributions())
                      # Unload pip module
                      del pip

                      # deactive/switch back to initial interpreter
                      deactivate()

                      # print list of initial environment pip packages for example purpose
                      import pip
                      print str(pip.get_installed_distributions())


                      Not 100% sure if it works as intended, I may have missed something completely.






                      share|improve this answer













                      Had the same problem myself while working on an installer script, I took a look at what the bin/activate_this.py did and reversed it.



                      Example:



                      #! /usr/bin/python
                      # -*- coding: utf-8 -*-
                      import os
                      import sys

                      # path to virtualenv
                      venv_path = os.path.join('/home', 'sixdays', '.virtualenvs', 'test32')

                      # Save old values
                      old_os_path = os.environ['PATH']
                      old_sys_path = list(sys.path)
                      old_sys_prefix = sys.prefix


                      def deactivate():
                      # Change back by setting values to starting values
                      os.environ['PATH'] = old_os_path
                      sys.prefix = old_sys_prefix
                      sys.path[:0] = old_sys_path


                      # Activate the virtualenvironment
                      activate_this = os.path.join(venv_path, 'bin/activate_this.py')
                      execfile(activate_this, dict(__file__=activate_this))


                      # Print list of pip packages for virtualenv for example purpose
                      import pip
                      print str(pip.get_installed_distributions())
                      # Unload pip module
                      del pip

                      # deactive/switch back to initial interpreter
                      deactivate()

                      # print list of initial environment pip packages for example purpose
                      import pip
                      print str(pip.get_installed_distributions())


                      Not 100% sure if it works as intended, I may have missed something completely.







                      share|improve this answer












                      share|improve this answer



                      share|improve this answer










                      answered Dec 11 '14 at 18:18









                      Lord SumnerLord Sumner

                      36434




                      36434








                      • 1





                        if deactivate resets value of environment path, system path, default prompt then your deactivate function is good approach. I like your script. Already given +1.

                        – Ramkumar D
                        Jun 6 '16 at 8:00














                      • 1





                        if deactivate resets value of environment path, system path, default prompt then your deactivate function is good approach. I like your script. Already given +1.

                        – Ramkumar D
                        Jun 6 '16 at 8:00








                      1




                      1





                      if deactivate resets value of environment path, system path, default prompt then your deactivate function is good approach. I like your script. Already given +1.

                      – Ramkumar D
                      Jun 6 '16 at 8:00





                      if deactivate resets value of environment path, system path, default prompt then your deactivate function is good approach. I like your script. Already given +1.

                      – Ramkumar D
                      Jun 6 '16 at 8:00





                      protected by dano May 6 '15 at 17:59



                      Thank you for your interest in this question.
                      Because it has attracted low-quality or spam answers that had to be removed, posting an answer now requires 10 reputation on this site (the association bonus does not count).



                      Would you like to answer one of these unanswered questions instead?



                      Popular posts from this blog

                      Xamarin.iOS Cant Deploy on Iphone

                      Glorious Revolution

                      Dulmage-Mendelsohn matrix decomposition in Python