Python pip requirements package

12. Virtual Environments and Packages¶

Python applications will often use packages and modules that don’t come as part of the standard library. Applications will sometimes need a specific version of a library, because the application may require that a particular bug has been fixed or the application may be written using an obsolete version of the library’s interface.

This means it may not be possible for one Python installation to meet the requirements of every application. If application A needs version 1.0 of a particular module but application B needs version 2.0, then the requirements are in conflict and installing either version 1.0 or 2.0 will leave one application unable to run.

The solution for this problem is to create a virtual environment , a self-contained directory tree that contains a Python installation for a particular version of Python, plus a number of additional packages.

Different applications can then use different virtual environments. To resolve the earlier example of conflicting requirements, application A can have its own virtual environment with version 1.0 installed while application B has another virtual environment with version 2.0. If application B requires a library be upgraded to version 3.0, this will not affect application A’s environment.

12.2. Creating Virtual Environments¶

The module used to create and manage virtual environments is called venv . venv will usually install the most recent version of Python that you have available. If you have multiple versions of Python on your system, you can select a specific Python version by running python3 or whichever version you want.

To create a virtual environment, decide upon a directory where you want to place it, and run the venv module as a script with the directory path:

python -m venv tutorial-env 

This will create the tutorial-env directory if it doesn’t exist, and also create directories inside it containing a copy of the Python interpreter and various supporting files.

A common directory location for a virtual environment is .venv . This name keeps the directory typically hidden in your shell and thus out of the way while giving it a name that explains why the directory exists. It also prevents clashing with .env environment variable definition files that some tooling supports.

Once you’ve created a virtual environment, you may activate it.

tutorial-env\Scripts\activate.bat 

source tutorial-env/bin/activate 

(This script is written for the bash shell. If you use the csh or fish shells, there are alternate activate.csh and activate.fish scripts you should use instead.)

Activating the virtual environment will change your shell’s prompt to show what virtual environment you’re using, and modify the environment so that running python will get you that particular version and installation of Python. For example:

$ source ~/envs/tutorial-env/bin/activate (tutorial-env) $ python Python 3.5.1 (default, May 6 2016, 10:59:36) . >>> import sys >>> sys.path ['', '/usr/local/lib/python35.zip', . '~/envs/tutorial-env/lib/python3.5/site-packages'] >>>

To deactivate a virtual environment, type:

12.3. Managing Packages with pip¶

You can install, upgrade, and remove packages using a program called pip. By default pip will install packages from the Python Package Index. You can browse the Python Package Index by going to it in your web browser.

pip has a number of subcommands: “install”, “uninstall”, “freeze”, etc. (Consult the Installing Python Modules guide for complete documentation for pip .)

You can install the latest version of a package by specifying a package’s name:

(tutorial-env) $ python -m pip install novas Collecting novas Downloading novas-3.1.1.3.tar.gz (136kB) Installing collected packages: novas Running setup.py install for novas Successfully installed novas-3.1.1.3

You can also install a specific version of a package by giving the package name followed by == and the version number:

(tutorial-env) $ python -m pip install requests==2.6.0 Collecting requests==2.6.0 Using cached requests-2.6.0-py2.py3-none-any.whl Installing collected packages: requests Successfully installed requests-2.6.0

If you re-run this command, pip will notice that the requested version is already installed and do nothing. You can supply a different version number to get that version, or you can run python -m pip install —upgrade to upgrade the package to the latest version:

(tutorial-env) $ python -m pip install --upgrade requests Collecting requests Installing collected packages: requests Found existing installation: requests 2.6.0 Uninstalling requests-2.6.0: Successfully uninstalled requests-2.6.0 Successfully installed requests-2.7.0

python -m pip uninstall followed by one or more package names will remove the packages from the virtual environment.

python -m pip show will display information about a particular package:

(tutorial-env) $ python -m pip show requests --- Metadata-Version: 2.0 Name: requests Version: 2.7.0 Summary: Python HTTP for Humans. Home-page: http://python-requests.org Author: Kenneth Reitz Author-email: me@kennethreitz.com License: Apache 2.0 Location: /Users/akuchling/envs/tutorial-env/lib/python3.4/site-packages Requires:

python -m pip list will display all of the packages installed in the virtual environment:

(tutorial-env) $ python -m pip list novas (3.1.1.3) numpy (1.9.2) pip (7.0.3) requests (2.7.0) setuptools (16.0) 

python -m pip freeze will produce a similar list of the installed packages, but the output uses the format that python -m pip install expects. A common convention is to put this list in a requirements.txt file:

(tutorial-env) $ python -m pip freeze > requirements.txt (tutorial-env) $ cat requirements.txt novas==3.1.1.3 numpy==1.9.2 requests==2.7.0

The requirements.txt can then be committed to version control and shipped as part of an application. Users can then install all the necessary packages with install -r :

(tutorial-env) $ python -m pip install -r requirements.txt Collecting novas==3.1.1.3 (from -r requirements.txt (line 1)) . Collecting numpy==1.9.2 (from -r requirements.txt (line 2)) . Collecting requests==2.7.0 (from -r requirements.txt (line 3)) . Installing collected packages: novas, numpy, requests Running setup.py install for novas Successfully installed novas-3.1.1.3 numpy-1.9.2 requests-2.7.0

pip has many more options. Consult the Installing Python Modules guide for complete documentation for pip . When you’ve written a package and want to make it available on the Python Package Index, consult the Distributing Python Modules guide.

Источник

Requirements File Format#

Requirements files serve as a list of items to be installed by pip, when using pip install . Files that use this format are often called “pip requirements.txt files”, since requirements.txt is usually what these files are named (although, that is not a requirement).

Note The requirements file format is closely tied to a number of internal details of pip (e.g., pip’s command line options). The basic format is relatively stable and portable but the full syntax, as described here, is only intended for consumption by pip, and other tools should take that into account before using it for their own purposes.

Example#

# This is a comment, to show how #-prefixed lines are ignored. # It is possible to specify requirements as plain names. pytest pytest-cov beautifulsoup4 # The syntax supported here is the same as that of requirement specifiers. docopt == 0.6.1 requests [security] >= 2.8.1, == 2.8.* ; python_version  "2.7" urllib3 @ https://github.com/urllib3/urllib3/archive/refs/tags/1.26.8.zip # It is possible to refer to other requirement files or constraints files. -r other-requirements.txt -c constraints.txt # It is possible to refer to specific local distribution paths. ./downloads/numpy-1.9.2-cp34-none-win32.whl # It is possible to refer to URLs. http://wxpython.org/Phoenix/snapshot-builds/wxPython_Phoenix-3.0.3.dev1820+49a8884-cp34-none-win_amd64.whl 

Structure#

For details on requirement specifiers, see Requirement Specifiers . For examples of all these forms, see Examples .

Encoding#

Requirements files are utf-8 encoding by default and also support PEP 263 style comments to change the encoding (i.e. # -*- coding: -*- ).

Line continuations#

A line ending in an unescaped \ is treated as a line continuation and the newline following it is effectively ignored.

Comments#

A line that begins with # is treated as a comment and ignored. Whitespace followed by a # causes the # and the remainder of the line to be treated as a comment.

Comments are stripped after line continuations are processed.

Supported options#

Requirements files only supports certain pip install options, which are listed below.

Global options#

The following options have an effect on the entire pip install run, and must be specified on their individual lines.

• -i, —index-url
• —extra-index-url
• —no-index
• -c, —constraint
• -r, —requirement
• -e, —editable
• -f, —find-links
• —no-binary
• —only-binary
• —prefer-binary
• —require-hashes
• —pre
• —trusted-host
• —use-feature

To specify —pre , —no-index and two —find-links locations:

--pre --no-index --find-links /my/local/archives --find-links http://some.archives.com/archives 

Per-requirement options#

The options which can be applied to individual requirements are:

Referring to other requirements files#

If you wish, you can refer to other requirements files, like this:

You can also refer to constraints files , like this:

Using environment variables#

pip supports the use of environment variables inside the requirements file.

You have to use the POSIX format for variable names including brackets around the uppercase name as shown in this example: $ . pip will attempt to find the corresponding environment variable defined on the host system at runtime.

There is no support for other variable expansion syntaxes such as $VARIABLE and %VARIABLE% .

You can now store sensitive data (tokens, keys, etc.) in environment variables and only specify the variable name for your requirements, letting pip lookup the value at runtime. This approach aligns with the commonly used 12-factor configuration pattern.

Influencing the build system#

This disables the use of wheels (cached or otherwise). This could mean that builds will be slower, less deterministic, less reliable and may not behave correctly upon installation.

This mechanism is only preserved for backwards compatibility and should be considered deprecated. A future release of pip may drop these options.

The —global-option option is used to pass options to setup.py .

These options are highly coupled with how pip invokes setuptools using the setup.py (legacy) build system interface. It is not compatible with newer pyproject.toml build system interface.

This is will not work with other build-backends or newer setup.cfg-only projects.

If you have a declaration like:

FooProject >= 1.2 --global-option="--no-user-cfg"

The above translates roughly into running FooProject’s setup.py script as:

python setup.py --no-user-cfg install

Note that the only way of giving more than one option to setup.py is through multiple —global-option options.

Источник