zoukankan      html  css  js  c++  java
  • virtualenv and virtualenvwrapper on Ubuntu 14.04

    In this post I’ll go over my attempt to setup virtual environments for Python development. Most Python users probably don’t want to use virtual environments and should just set up a single user environment that works for their needs. However, if you are working on writing one or more Python modules or packages, these tools are geared towards creating isolated Python environments for each project. This is very useful for keeping track of such things as the minimal Python requirements for each project.

     

    Assuming you want to proceed, my goal is to setup and usevirtualenvwrapper (see virtualenvwrapper docs for more info), a set of shell tools wrapped around the virtualenv package. Both the Doug Hellman post and the simonsoftware post provide some motivation for the development and use of the wrapper formulation– in simple termsvirtualenvwrapper provides some shortcuts for common actions. So, I’ve decided to use the wrapped version.

    Basic install

    Following the virtualenvwrapper basic install, the installation process is to install virtualenv and virtualenvwrapper using pip. I have already installed virtualenv, as can be seen by using pip show:

    $ pip show virtualenv
    ---
    Name: virtualenv
    Version: 1.11.6
    Location: /home/cstrelioff/.local/lib/python2.7/site-packages
    Requires:
    

    If you need to install, the command is – I install as a user:

    $ pip install --user virtualenv
    

    Next, install the virtualenvwrapper:

    $ pip install --user virtualenvwrapper
    

    Now a pip show should show something like:

    $ pip show virtualenvwrapper
    ---
    Name: virtualenvwrapper
    Version: 4.3.1
    Location: /home/cstrelioff/.local/lib/python2.7/site-packages
    Requires: virtualenv, virtualenv-clone, stevedore
    

    Finally, we add some information to our ~/.bashrc file – I added to the end of the file, as usual for such things. The actual contents for you will be different.

    • I wanted my virtual environments in ~/virtenvs/ and I had already made that directory.
    • I want to keep my active projects in ~/Projects-Active/, an existing directory.
    • Finally, because I installed as a user, the path to myvirtualenvwrapper.sh is in ~/.local/bin/, as indicated by usingwhich:
    $ which virtualenvwrapper.sh
    /home/cstrelioff/.local/bin/virtualenvwrapper.sh
    

    Putting all of that specific information together, I added the following to ~/.bashrc:

    # where to store our virtual envs
    export WORKON_HOME=$HOME/virtenvs
    # where projects will reside
    export PROJECT_HOME=$HOME/Projects-Active
    # where is the virtualenvwrapper.sh
    source $HOME/.local/bin/virtualenvwrapper.sh
    

    After saving the changes, I sourced the file to make the changes active:

    $ source ~/.bashrc
    

    Working with virtualenvs

    Next up, let’s figure out how to use all this– you should also look at the simonsoftware post for another take on this. The main command to remember is workon, as in I’m going to work on this project. However, if we try it now we get nothing:

    $ workon
    $
    

    We need to make a virtual environment. So, let’s make one:

    $ mkvirtualenv test_env01
    New python executable in test_env01/bin/python
    Installing setuptools, pip...done.
    

    We can use pip list to see the packages available:

    (test_env01)$ pip list
    argparse (1.2.1)
    pip (1.5.6)
    setuptools (3.6)
    wsgiref (0.1.2)
    

    Notice that the command prompt has changed to include the environment name. If we want to install a package in this environment we use pip:

    (test_env01)$ pip install pyaml
    

    Now, a pip list gives:

    (test_env01)$ pip list
    argparse (1.2.1)
    pip (1.5.6)
    pyaml (14.05.7)
    PyYAML (3.11)
    setuptools (3.6)
    wsgiref (0.1.2)
    

    To deactivate the virtual environment, we type exactly what you’d expect:

    (test_env01)$ deactivate
    $
    

    and we get back to the normal command prompt. However, now theworkon command will show the virtual environment that we created:

    $ workon
    test_env01
    $
    

    To start working on it again, simply try out the following to see everything is there:

    $ workon test_env01
    (test_env01)$ pip list
    argparse (1.2.1)
    pip (1.5.6)
    pyaml (14.05.7)
    PyYAML (3.11)
    setuptools (3.6)
    wsgiref (0.1.2)
    (test_env01)$ deactivate
    

    Projects in virtualenvwrapper

    Finally, let’s talk about projects in virtualenvwrapper. This creates both (i) a virtual environment and (ii) a project directory in the location specified by PROJECT_HOME variable in the additions to the~/.bashrc file. Let’s try it out:

    $ mkproject test_project02
    New python executable in test_project02/bin/python
    Installing setuptools, pip...done.
    Creating /home/cstrelioff/Projects-Active/test_project02
    Setting project for test_project02 to
    /home/cstrelioff/Projects-Active/test_project02
    (test_project02)~/Projects-Active/test_project02$
    

    Notice that this also creates a directory and cd’s to directory– very nice! Now, if we try pip list we’ll see only the packages for a new environmnet:

    (test_project02)~/Projects-Active/test_project02$ pip list
    argparse (1.2.1)
    pip (1.5.6)
    setuptools (3.6)
    wsgiref (0.1.2)
    

    Switching between environments

    Now we have two virtual environments setup, but only one is setup as a project. We can see both with workon:

    $ workon
    test_env01
    test_project02
    

    To get a sense of how this all works, let startup test_env01 and usepip list to see that PyYAML is installed:

    $ workon test_env01
    (test_env01)$ pip list
    argparse (1.2.1)
    pip (1.5.6)
    pyaml (14.05.7)
    PyYAML (3.11)
    setuptools (3.6)
    wsgiref (0.1.2)
    

    Next, while in test_env01, let’s switch to test_project02 usingworkon and look at the installed packages (no PyYAML):

    (test_env01)$ workon test_project02
    (test_project02)~/Projects-Active/test_project02$ pip list
    argparse (1.2.1)
    pip (1.5.6)
    setuptools (3.6)
    wsgiref (0.1.2)
    

    Notice that the workon cd’s to the project directory. This happens because we setup test_project02 as a project and not just avirtualenv. If you use workon to switch back to test_env01 there will be no cd because there is no project file associated with that virtual environment. In practice I imagine I will always use mkproject to set things up.

    Cleaning up

    Finally, to clean up the example above we can use rmvirtualenv:

    $ workon
    test_env01
    test_project02
    $ rmvirtualenv test_env01
    Removing test_env01...
    $ rmvirtualenv test_project02
    Removing test_project02...
    $ workon
    $
    

    With the final workon we can see that all of our environments are gone. However, note that the directory created in PROJECT_HOMEwill not be deleted by the above– this is probably a good default behaviour. You’ll have to go delete the directory (if you want).

    That’s it, hopefully some will find this useful post useful. If you have cool/better ways to use these tools leave a comment below.

  • 相关阅读:
    JCreator的配置
    哈夫曼编码
    最小生成树
    逻辑左移右移与算术左移右移
    原码 反码 补码 移码
    hdu 小希的迷宫
    (二)Qt窗口应用程序Widget
    (一)Qt5模块,QtCreator常用快捷键,命名规范
    if __name__="__main__"
    数据库之sql语句汇总
  • 原文地址:https://www.cnblogs.com/descusr/p/4643754.html
Copyright © 2011-2022 走看看