"Python" virtualenv Virtual environment construction and management

"Virtualenv"

One of the big problems with Python development is that the dependency packages that each project requires are inconsistent. If the package itself is not as good, if the different projects need a different version of the package, it will be very troublesome. In the case of a unified system Python environment (where the system Python environment is defined, for example, the directory where Python is installed on Windows is default to all Python-related content under directories such as C:\PYTHON27, Linux has its own python Refers to the python environment that the system comes with. For example, third-party libraries are stored under/usr/lib/python2.7/site-packages and so on) development, packages are only one set can not be differentiated by project.

The solution to this problem is to use a virtual environment to develop and maintain different projects. The so-called virtual environment, in fact, is to say in the system Python environment outside a set of Python environment, this set of Python environment may borrow part of the system Python environment content, and self-supplement others. Programs that are in the context of a virtual environment will run according to the boundaries given by the virtual environment.

A simple tool for building and managing virtual environments is virtualenv. Virtualenv is available on both the Linux platform and the Windows platform, and it changes some configurations to fit the current OS based on the specific platform on which it resides.

Installation virtualenv is very convenient, as long as Pip install virtualenv can. This shows that virtualenv is actually a package written in Python. But the more convenient part is that during PIP installation, we set up a virtualenv executable file for us under the system's executable directory (under Linux,/usr/bin). This means that you can type virtualenv directly on the command line. The following will be based on Linux (CENTOS7), explaining the use of virtualenv.

Basic use

At the command line, type Virtualenv < virtual environment directory name > to generate a directory of virtual environments at the current location, the directory name of the virtual environment, which is the name of the virtual environment. Open this directory we can see the main bin,include,lib and other directories, which focus on the bin and Lib two directory. The bin directory, as the name implies, is a few executable binaries, which can be seen in addition to Python and several different names in the Python soft chain, as well as Pip and Easy_install. As you know, the virtual environment is built with two important tools, Pip and Easy_install, to facilitate the construction of the following environment. The Lib directory can see that there is a site-packages directory at the bottom. This directory is, of course, a directory of third-party libraries, which are generated by default with only a few basic third-party packages. . (Just a moment ago, the main difference between--no-site-packages and--system-site-packages is that when the virtual environment is set up for PIP installation, if there is a package in the system environment that you want to install, Specifying--no-site-packages will copy that package into the virtual environment's LIB, which will not. But it's not absolutely. For example, I think pip install Flask Flask-bootstrap, when the flask package can really reflect the difference, but when the flask-bootstrap, no matter what parameters Flask-bootstrap file is not copied over. )

In addition, you can see a activate file under the directory. This file is the entry into the virtual environment. Type source activate to see the command line prompt with a parenthesis in front of the name of the virtual environment. After entering the virtual environment, typing commands such as Pip,python is no longer the command in the system Python environment. With which python you can look at it, the display should not be/usr/bin/python. Therefore, in this environment (regardless of which directory you are in), as long as the Python command is invoked to run the script, the context of the third-party library it uses is the context of the virtual environment. So in the virtual environment of the Lib directory to install the desired third-party package, and then use the virtual environment of the Python launcher, you can make this program or project in a relatively independent closed environment.

When it comes to installation, the virtual environment comes with a PIP, which prompts us to install with PIP. and PIP installation is convenient, if you want to install the package already exists in the system Python environment, then Pip will not go to pypi above download, but directly from the system environment copied from the good, so the installation speed is greatly improved. In addition, with PIP freeze > requirement.txt This command can solidify the requirements and dependencies of Python packages in the context of the virtual environment to the Requirement.txt file. When the program is migrated but the environment is not migrated, simply type Pip Install-r requirement.txt in the new environment to install all of these dependencies in one breath. It's easy to combine virtual environments with Pip freeze two of things.

Questions about Program Migration

During the development of the project, the production environment is often encountered after the development environment is completed, but the Python environment of the production environment is not necessarily consistent with the development environment, causing a lot of trouble.

In this case, you can save energy with a virtual environment. For example, the production environment is loaded with virtualenv, then you can build a virtual environment in the right place, and then activate into this virtual environment, according to the development environment cured requirement.txt in the virtual environment PIP Install-r Requirement.txt. All the dependencies can be loaded in a breath. Then into the virtual environment, with the virtual Environment Python launcher (or directly through the path to the virtual environment directory Bin/python to start) can be done as the development environment.

But it is better to do so, if the production environment is not net it? Then you have to think of another way. It's a good idea to set up a virtual environment in a network and then PIP install the related packages and then copy those files over again, but it's a little tricky. Another way to do this is to copy the entire virtual environment of the development environment directly to the production environment, if the path after the replication has changed compared to the development environment, then you can change the Activate virtual_env this will be added to the environment variable as a new directory, This ensures that the virtual environment that the source activate comes out of remains a virtual environment rather than a system environment. (In fact, look at the Activate code is not difficult to find that the so-called virtual environment only when the source activate added a little environment variables, including the virtual environment to add the bin directory in the path and before all the original path, So when you type Python, you call Python for the virtual environment, and some of the other environment variables are similar. Deactivate is to restore these environment variables to their original values. Then add a startup script to the project, which first goes into the virtual environment and then calls the Python launcher, all the same as the development environment.

Please note: There is a big premise for the migration above to be successful, that is, the Python version of the production environment and development environment is the same ... If developed under python2.7, migration to 2.6 is likely to report a lack of errors such as libpython2.7.so.1.0. If you really want to solve this problem in one place, like porting the program to a Python-free environment, you need to install the entire python.

Virtualenv under Windows

The virtualenv generated under Windows is not quite the same as the directory for the virtual environment under Linux. The main difference is that the bin directory is renamed to the scripts directory and contains some. exe files including activate. Then Lib was called Lib. Everything else seems to be similar.

Virtualenvwrapper

You can add it when you are free.

"Python" virtualenv Virtual environment construction and management