Requirements txt python как установить

User Guide#

Running pip#

pip is a command line program. When you install pip, a pip command is added to your system, which can be run from the command prompt as follows:

Installing Packages#

pip supports installing from PyPI, version control, local projects, and directly from distribution files.

The most common scenario is to install from PyPI using Requirement Specifiers

For more information and examples, see the pip install reference.

Basic Authentication Credentials

Using a Proxy Server#

When installing packages from PyPI, pip requires internet access, which in many corporate environments requires an outbound HTTP proxy server.

pip can be configured to connect through a proxy server in various ways:

using the environment variable PIP_USER_AGENT_USER_DATA to include a JSON-encoded string in the user-agent variable used in pip’s requests.

Requirements Files#

“Requirements files” are files containing a list of items to be installed using pip install like so:

Logically, a Requirements file is just a list of pip install arguments placed in a file. Note that you should not rely on the items in the file being installed by pip in any particular order.

In practice, there are 4 common uses of Requirements files:

If SomeDependency was previously a top-level requirement in your requirements file, then replace that line with the new line. If SomeDependency is a sub-dependency, then add the new line.

It’s important to be clear that pip determines package dependencies using install_requires metadata, not by discovering requirements.txt files embedded in projects.

Constraints Files#

Use a constraints file like so:

Constraints files are used for exactly the same reason as requirements files when you don’t know exactly what things you want to install. For instance, say that the “helloworld” package doesn’t work in your environment, so you have a local patched version. Some things you install depend on “helloworld”, and some don’t.

One way to ensure that the patched version is used consistently is to manually audit the dependencies of everything you install, and if “helloworld” is present, write a requirements file to use when installing that thing.

Constraints files offer a better way: write a single constraints file for your organisation and use that everywhere. If the thing being installed requires “helloworld” to be installed, your fixed version specified in your constraints file will be used.

Constraints file support was added in pip 7.1. In Changes to the pip dependency resolver in 20.3 (2020) we did a fairly comprehensive overhaul, removing several undocumented and unsupported quirks from the previous implementation, and stripped constraints files down to being purely a way to specify global (version) limits for packages.

Installing from Wheels#

If no satisfactory wheels are found, pip will default to finding source archives.

To install directly from a wheel archive:

To include optional dependencies provided in the provides_extras metadata in the wheel, you must add quotes around the install target name:

In the future, the path[extras] syntax may become deprecated. It is recommended to use PEP 508 syntax wherever possible.

For the cases where wheels are not available, pip offers pip wheel as a convenience, to build wheels for all your requirements and dependencies.

pip wheel requires the wheel package to be installed, which provides the “bdist_wheel” setuptools extension that it uses.

To build wheels for your requirements and all their dependencies to a local directory:

And then to install those requirements just using your local directory of wheels (and not from PyPI):

Uninstalling Packages#

pip is able to uninstall most packages like so:

pip also performs an automatic uninstall of an old version of a package before upgrading to a newer version.

For more information and examples, see the pip uninstall reference.

Listing Packages#

To list installed packages:

To list outdated packages, and show the latest version available:

To show details about an installed package:

For more information and examples, see the pip list and pip show reference pages.

Searching for Packages#

pip can search PyPI for packages using the pip search command:

The query will be used to search the names and summaries of all packages.

For more information and examples, see the pip search reference.

Command Completion#

pip comes with support for command line completion in bash, zsh and fish.

To setup for powershell:

Alternatively, you can use the result of the completion command directly with the eval function of your shell, e.g. by adding the following to your startup file:

Installing from local packages#

In some cases, you may want to install from local packages only, with no traffic to PyPI.

First, download the archives that fulfill your requirements:

Note that pip download will look in your wheel cache first, before trying to download from PyPI. If you’ve never installed your requirements before, you won’t have a wheel cache for those items. In that case, if some of your requirements don’t come as wheels from PyPI, and you want wheels, then run this instead:

“Only if needed” Recursive Upgrade#

eager : upgrades all dependencies regardless of whether they still satisfy the new parent requirements

only-if-needed : upgrades a dependency only if it does not satisfy the new parent requirements

As an historic note, an earlier “fix” for getting the only-if-needed behaviour was:

A proposal for an upgrade-all command is being considered as a safer alternative to the behaviour of eager upgrading.

User Installs#

To install “SomePackage” into an environment with site.USER_BASE customized to ‘/myappenv’, do the following:

When globally installed packages are on the python path, and they conflict with the installation requirements, they are ignored, and not uninstalled.

To make the rules clearer, here are some examples:

From within a real python, where SomePackage is not installed globally:

From within a real python, where SomePackage is installed globally, but is not the latest version:

From within a real python, where SomePackage is installed globally, and is the latest version:

Fixing conflicting dependencies

Using pip from your program#

The pip code assumes that is in sole control of the global state of the program. pip manages things like the logging system configuration, or the values of the standard IO streams, without considering the possibility that user code might be affected.

pip’s code is not thread safe. If you were to run pip in a thread, there is no guarantee that either your code or pip’s would work as you expect.

pip assumes that once it has finished its work, the process will terminate. It doesn’t need to handle the possibility that other code will continue to run after that point, so (for example) calling pip twice in the same process is likely to have issues.

What this means in practice is that everything inside of pip is considered an implementation detail. Even the fact that the import name is pip is subject to change without notice. While we do try not to break things as much as possible, all the internal APIs can change at any time, for any reason. It also means that we generally won’t fix issues that are a result of using pip in an unsupported way.

It should also be noted that installing packages into sys.path in a running Python process is something that should only be done with care. The import system caches certain data, and installing new packages while a program is running may not always behave as expected. In practice, there is rarely an issue, but it is something to be aware of.

Having said all of the above, it is worth covering the options available if you decide that you do want to run pip from within your program. The most reliable approach, and the one that is fully supported, is to run pip in a subprocess. This is easily done using the standard subprocess module:

If you want to process the output further, use one of the other APIs in the module. We are using freeze here which outputs installed packages in requirements format.:

If you don’t want to use pip’s command line functionality, but are rather trying to implement code that works with Python packages, their metadata, or PyPI, then you should consider other, supported, packages that offer this type of ability. Some examples that you could consider include:

Changes to the pip dependency resolver in 20.3 (2020)#

pip 20.3 has a new dependency resolver, on by default for Python 3 users. (pip 20.1 and 20.2 included pre-release versions of the new dependency resolver, hidden behind optional user flags.) Read below for a migration guide, how to invoke the legacy resolver, and the deprecation timeline. We also made a two-minute video explanation you can watch.

We will continue to improve the pip dependency resolver in response to testers’ feedback. Please give us feedback through the resolver testing survey.

Watch out for#

The big change in this release is to the pip dependency resolver within pip.

The most significant changes to the resolver are:

So, if you have been using workarounds to force pip to deal with incompatible or inconsistent requirements combinations, now’s a good time to fix the underlying problem in the packages, because pip will be stricter from here on out.

Constraints don’t override the existing requirements; they simply constrain what versions are visible as input to the resolver (see #9020)

Hash-checking mode requires that all requirements are specified as a == match on a version and may not work well in combination with constraints (see #9020 and #8792)

If necessary to satisfy constraints, pip will happily reinstall packages, upgrading or downgrading, without needing any additional command-line options (see #8115 and Options that control the installation process )

Unnamed requirements are not allowed as constraints (see #6628 and #8210)

Links are not allowed as constraints (see #8253)

Constraints cannot have extras (see #6628)

Per our Python 2 Support policy, pip 20.3 users who are using Python 2 will use the legacy resolver by default. Python 2 users should upgrade to Python 3 as soon as possible, since in pip 21.0 in January 2021, pip dropped support for Python 2 altogether.

How to upgrade and migrate#

Test the new version of pip.

While we have tried to make sure that pip’s test suite covers as many cases as we can, we are very aware that there are people using pip with many different workflows and build processes, and we will not be able to cover all of those without your help.

installing several packages simultaneously

re-creating an environment using a requirements.txt file

using constraints files

the “Setups to test with special attention” and “Examples to try” below

If you have a build pipeline that depends on pip installing your dependencies for you, check that the new resolver does what you need.

Run your project’s CI (test suite, build process, etc.) using the new resolver, and let us know of any issues.

If you develop or support a tool that wraps pip or uses it to deliver part of your functionality, please test your integration with pip 20.3.

Troubleshoot and try these workarounds if necessary.

If pip is taking longer to install packages, read Dependency resolution backtracking for ways to reduce the time pip spends backtracking due to dependency conflicts.

Please report bugs through the resolver testing survey.

Setups to test with special attention#

Requirements files with 100+ packages

Installation workflows that involve multiple requirements files

Requirements files that include hashes ( Hash-checking Mode ) or pinned dependencies (perhaps as output from pip-compile within pip-tools )

Continuous integration/continuous deployment setups

Installing from any kind of version control systems (i.e., Git, Subversion, Mercurial, or CVS), per VCS Support

Installing from source code held in local directories

How can I install packages using pip according to the requirements.txt file from a local directory?

Here is the problem:

I have a requirements.txt file that looks like:

I have a local archive directory containing all the packages + others.

I have created a new virtualenv with

Upon activating it, I tried to install the packages according to requirements.txt from the local archive directory.

I got some output that seems to indicate that the installation is fine:

But a later check revealed that none of the packages are installed properly. I cannot import the packages, and none are found in the site-packages directory of my virtualenv. So what went wrong?

16 Answers 16

Trending sort

Trending sort is based off of the default sorting method — by highest score — but it boosts votes that have happened recently, helping to surface more up-to-date answers.

It falls back to sorting by highest score if no posts are trending.

Switch to Trending sort

This works for everyone:

Explanation:

Install from the given requirements file. This option can be used multiple times.

If a local path or file:// URL that’s a directory, then look for archives in the directory listing.

For virtualenv to install all files in the requirements.txt file.

I had a similar problem. I tried this:

(-U = update if it had already installed)

But the problem continued. I realized that some of generic libraries for development were missed.

I don’t know if this would help you.

For further details, please check the help option:

Further information on some commonly used pip install options (this is the help option on the pip install command):

Short answer

or in another form:

Explanation

pip will start installation only after checking the availability of all listed items in the requirements file and it won’t start installation even if one requirement is unavailable.

One workaround to install the available packages is installing listed packages one by one. Use the following command for that. A red color warning will be shown to notify you about the unavailable packages.

To ignore comments (lines starting with a # ) and blank lines, use:

First of all, create a virtual environment.

Then activate the environment and install all the packages available in the requirement.txt file.

Often, you will want a fast install from local archives, without probing PyPI.

First, download the archives that fulfill your requirements:

Then, install using –find-links and –no-index :

I work with a lot of systems that have been mucked by developers «following directions they found on the Internet». It is extremely common that your pip and your python are not looking at the same paths/site-packages. For this reason, when I encounter oddness I start by doing this:

That is a happy system.

Below is an unhappy system. (Or at least it’s a blissfully ignorant system that causes others to be unhappy.)

It is unhappy because pip is (python3.6 and) using /usr/local/lib/python3.6/site-packages while python is (python2.7 and) using /usr/local/lib/python2.7/site-packages

When I want to make sure I’m installing requirements to the right python, I do this:

You’ve heard, «If it ain’t broke, don’t try to fix it.» The DevOps version of that is, «If you didn’t break it and you can work around it, don’t try to fix it.»

pip install¶

Usage¶

Description¶

Install packages from:

pip also supports installing from “requirements files”, which provide an easy way to specify a whole environment to be installed.

Overview¶

Pip install has several stages:

Argument Handling¶

When looking at the items to be installed, pip checks what type of item each is, in the following order:

Each item identified is added to the set of requirements to be satisfied by the install.

Working Out the Name and Version¶

Any URL may use the #egg=name syntax (see VCS Support ) to explicitly state the project name.

Satisfying Requirements¶

Once pip has the set of requirements to satisfy, it chooses which version of each requirement to install using the simple rule that the latest version that satisfies the given constraints will be installed (but see here for an exception regarding pre-release versions). Where more than one source of the chosen version is available, it is assumed that any source is acceptable (as otherwise the versions would differ).

Installation Order¶

As of v6.1.0, pip installs dependencies before their dependents, i.e. in “topological order”. This is the only commitment pip currently makes related to order. While it may be coincidentally true that pip will install things in the order of the install arguments or in the order of the items in a requirements file, this is not a promise.

In the event of a dependency cycle (aka “circular dependency”), the current implementation (which might possibly change later) has it such that the first encountered member of the cycle is installed last.

For instance, if quux depends on foo which depends on bar which depends on baz, which depends on foo:

Prior to v6.1.0, pip made no commitments about install order.

The decision to install topologically is based on the principle that installations should proceed in a way that leaves the environment usable at each step. This has two main practical benefits:

Although the new install order is not intended to replace (and does not replace) the use of setup_requires to declare build dependencies, it may help certain projects install from sdist (that might previously fail) that fit the following profile:

Requirements File Format¶

See the pip install Examples for examples of all these forms.

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.

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

Comments are stripped before line continuations are processed.

The following options are supported:

For example, to specify –no-index and 2 –find-links locations:

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

Example Requirements File¶

Requirement Specifiers¶

Since version 6.0, pip also supports specifiers containing environment markers like so:

Environment markers are supported in the command line and in requirements files.

Per-requirement Overrides¶

Since version 7.0 pip supports controlling the command line options given to setup.py via requirements files. This disables the use of wheels (cached or otherwise) for that package, as setup.py does not exist for wheels.

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

Pre-release Versions¶

Starting with v1.4, pip will only install stable versions as specified by PEP426 by default. If a version cannot be parsed as a compliant PEP426 version then it is assumed to be a pre-release.

The pip install command also supports a –pre flag that will enable installing pre-releases and development releases.

VCS Support¶

pip supports installing from Git, Mercurial, Subversion and Bazaar, and detects the type of VCS using url prefixes: “git+”, “hg+”, “bzr+”, “svn+”.

pip requires a working VCS command on your path: git, hg, svn, or bzr.

VCS projects can be installed in editable mode (using the –editable option) or not.

The “project name” component of the url suffix “egg=

— ” is used by pip in its dependency logic to identify the project prior to pip downloading and analyzing the metadata. The optional “version” component of the egg name is not functionally important. It merely provides a human-readable clue as to what version is in use. For projects where setup.py is not in the root of project, “subdirectory” component is used. Value of “subdirectory” component should be a path starting from root of the project to where setup.py is located.

So if your repository layout is:

Here are the supported forms:

Passing branch names, a commit hash or a tag name is possible like so:

Mercurial¶

Here are the supported forms:

You can also specify a revision number, a revision hash, a tag name or a local branch name like so:

Subversion¶

You can also give specific revisions to an SVN URL, like so:

Bazaar¶

Here are the supported forms:

Tags or revisions can be installed like so:

Finding Packages¶

pip searches for packages on PyPI using the http simple interface, which is documented here and there

pip offers a number of Package Index Options for modifying how packages are found.

SSL Certificate Verification¶

Starting with v1.3, pip provides SSL certificate verification over https, to prevent man-in-the-middle attacks against PyPI downloads.

Caching¶

When making any HTTP request pip will first check its local cache to determine if it has a suitable response stored for that request which has not expired. If it does then it simply returns that response and doesn’t make the request.

If it has a response stored, but it has expired, then it will attempt to make a conditional request to refresh the cache which will either return an empty response telling pip to simply use the cached item (and refresh the expiration timer) or it will return a whole new response which pip can then store in the cache.

When storing items in the cache, pip will respect the CacheControl header if it exists, or it will fall back to the Expires header if that exists. This allows pip to function as a browser would, and allows the index server to communicate to pip how long it is reasonable to cache any particular item.

The default location for the cache directory depends on the Operating System:

/.cache/pip and it respects the XDG_CACHE_HOME directory. macOS

Wheel Cache¶

When no wheels are found for an sdist, pip will attempt to build a wheel automatically and insert it into the wheel cache.

Hash-Checking Mode¶

Since version 8.0, pip can check downloaded package archives against local hashes to protect against remote tampering. To verify a package against one or more hashes, add them to the end of the line:

(The ability to use multiple hashes is important when a package has both binary and source distributions or when it offers binary distributions for a variety of platforms.)

This can be useful in deploy scripts, to ensure that the author of the requirements file provided hashes. It is also a convenient way to bootstrap your list of hashes, since it shows the hashes of the packages it fetched. It fetches only the preferred archive for each package, so you may still need to add hashes for alternatives archives using pip hash : for instance if there is both a binary and a source distribution.

The wheel cache is disabled in hash-checking mode to prevent spurious hash mismatch errors. These would otherwise occur while installing sdists that had already been automatically built into cached wheels: those wheels would be selected for installation, but their hashes would not match the sdist ones from the requirements file. A further complication is that locally built wheels are nondeterministic: contemporary modification times make their way into the archive, making hashes unpredictable across machines and cache flushes. Compilation of C code adds further nondeterminism, as many compilers include random-seeded values in their output. However, wheels fetched from index servers are the same every time. They land in pip’s HTTP cache, not its wheel cache, and are used normally in hash-checking mode. The only downside of having the wheel cache disabled is thus extra build time for sdists, and this can be solved by making sure pre-built wheels are available from the index server.

Hashes from PyPI¶

“Editable” Installs¶

“Editable” installs are fundamentally “setuptools develop mode” installs.

You can install local projects or VCS projects in “editable” mode:

(See the VCS Support section above for more information on VCS-related syntax.)

Controlling setup_requires¶

Setuptools offers the setup_requires setup() keyword for specifying dependencies that need to be present in order for the setup.py script to run. Internally, Setuptools uses easy_install to fulfill these dependencies.

pip has no way to control how these dependencies are located. None of the Package Index Options have an effect.

The solution is to configure a “system” or “personal” Distutils configuration file to manage the fulfillment.

For example, to have the dependency located at an alternate index, add this:

To have the dependency located from a local directory and not crawl PyPI, add this:

Build System Interface¶

In order for pip to install a package from source, setup.py must implement the following commands:

The egg_info command should create egg metadata for the package, as described in the setuptools documentation at https://setuptools.readthedocs.io/en/latest/setuptools.html#egg-info-create-egg-metadata-and-set-build-tags

The install command should implement the complete process of installing the package to the target directory XXX.

This should implement the complete process of installing the package in “editable” mode.

All packages will be attempted to built into wheels:

One further setup.py command is invoked by pip install :

This command is invoked to clean up temporary commands from the build. (TODO: Investigate in more detail when this command is required).

No other build system commands are invoked by the pip install command.

Installing a package from a wheel does not invoke the build system at all.

Options¶

Install from the given requirements file. This option can be used multiple times.

Constrain versions using the given constraints file. This option can be used multiple times.

Don’t install package dependencies.

Include pre-release and development versions. By default, pip only finds stable versions.

Install a project in editable mode (i.e. setuptools “develop mode”) from a local project path or a VCS url.

Install to the Python user install directory for your platform. Typically

/.local/, or %APPDATA%Python on Windows. (See the Python documentation for site.USER_BASE for full details.)

Install everything relative to this alternate root directory.

Installation prefix where lib, bin and other top-level folders are placed

Directory to unpack packages into and build in.

Directory to check out editable projects into. The default in a virtualenv is “ /src”. The default for global installs is “ /src”.

Upgrade all specified packages to the newest available version. The handling of dependencies depends on the upgrade-strategy used.

When upgrading, reinstall all packages even if they are already up-to-date.

Ignore the installed packages (reinstalling instead).

Ignore the Requires-Python information.

Extra arguments to be supplied to the setup.py install command (use like –install-option=”–install-scripts=/usr/local/bin”). Use multiple –install-option options to pass multiple options to setup.py install. If you are using an option with a directory path, be sure to use absolute path.

Extra global options to be supplied to the setup.py call before the install command.

Compile Python source files to bytecode

Do not compile Python source files to bytecode

Do not use binary packages. Can be supplied multiple times, and each time adds to the existing value. Accepts either :all: to disable all binary packages, :none: to empty the set, or one or more package names with commas between them. Note that some packages are tricky to compile and may fail to install when this option is used on them.

Do not use source packages. Can be supplied multiple times, and each time adds to the existing value. Accepts either :all: to disable all source packages, :none: to empty the set, or one or more package names with commas between them. Packages without binary distributions will fail to install when this option is used on them.

Don’t clean up build directories.

Require a hash to check each requirement against, for repeatable installs. This option is implied when any package in a requirements file has a –hash option.

Specify type of progress to be displayed [ascii|pretty|on|off|emoji] (default: on)

Base URL of Python Package Index (default https://pypi.python.org/simple). This should point to a repository compliant with PEP 503 (the simple repository API) or a local directory laid out in the same format.

Extra URLs of package indexes to use in addition to –index-url. Should follow the same rules as –index-url.

Ignore package index (only looking at –find-links URLs instead).

If a url or path to an html file, then parse for links to archives. If a local path or file:// url that’s a directory, then look for archives in the directory listing.

Enable the processing of dependency links.

Examples¶

Install SomePackage and its dependencies from PyPI using Requirement Specifiers

Upgrade an already installed SomePackage to the latest from PyPI.

Install a package with setuptools extras.

Install a particular source archive file.

Install from alternative package repositories.

Install from a different index, and not PyPI

Search an additional index during install, in addition to PyPI

Install from a local flat directory containing archives (and don’t scan indexes):

Find pre-release and development versions, in addition to stable versions. By default, pip only finds stable versions.

Управление Python пакетами с помощью pip

Данная статья является пошаговым введением в базовые навыки управления пакетами Python с помощью команды pip. В ней будут освещены следующие моменты:

Поиск пакетов Python

Рассмотрим случай использования пакета emoji в качестве примера. Для поиска Python пакетов, связанных с emoji, перейдём на веб сайт PyPi и через окно поиска в правом верхнем углу страницы поищем emoji.

Обратите внимание на колонку «Weight*» в середине таблицы. Это ключевая информация. Значение веса – это специфический рейтинг, который сайт рассчитывает для каждого пакета, чтобы ранжировать результаты поиска.

Согласно самому сайту, то рейтинг вычисляется на основе полей: имя, сводка, ключевые слова, описание, автор, мейнтейнер. Означает ли что найден лучший пакет? Не обязательно. Несмотря на необычность, сторонние пакеты своим присутствием могут затенять emoji.

Напротив, многие разработчики не удосуживаются заполнять все поля для своих пакетов, что приводит к тому, что эти пакеты занимают более низкие позиции.

В какой среде будет работать emoji? Приложение на основе терминала или, возможно, веб-приложение Django? Если нужно отобразить emoji в веб-приложении django, то лучше воспользоваться пакетом django-emoji. Для нашего случая предпочтительным вариантом является emoji для Python приложения командной строки.

На что нужно обратить внимание?

Далее приведены характеристики хорошего пакета Python:

Достойная документация: прочитав её, сразу становится понятно, соответствует ли пакет потребности или нет;

Зрелость и стабильность: если он существует уже продолжительное время, а также последними версиями;

Количество контрибьюторов: востребованные пакеты (особенно сложные), как правило, контрибьютятся большим количеством разработчиков;

Техническое обслуживание: он регулярно проходит техническое обслуживание.

На нашем случае документация выглядит достаточно прилично. В верхней части страницы показано графическое представление работы пакета emoji в интерпретаторе Python.

Документация для пакета emoji также рассказывает об его установке, как внести свой вклад в разработку, а также ссылку на страницу с исходниками, что является отличным источником полезной информации о нём.

Установка пакетов Python с помощью pip

Начиная с Python 3.4, pip входит в комплект поставки.

Также рекомендуется использовать виртуальную среду для управление рабочим процессом разработки и упрощения работы над несколькими проектами одновременно без возникновения конфликтов в их зависимостях.

Рассмотрим команду freeze, которая является ключевой в разрешении зависимостей. Запуск pip freeze отображает список всех установленных пакетов Python. Если выполнить с инструкцию с активной виртуальной средой, то будет распечатан пустой список

Для установки пакета, выполним pip install emoji в терминале. В результате будет получен следующий вывод:

При установке пакетов с помощью pip можем ограничить выборку установив предпочтительную версию предпочтения, используя следующие операторы:

Конкретная версия пакета (==):

Версия, отличная от указанной (! =):

Версия, равная или превышающая конкретную версию (> =):

Installing Packages¶

It’s important to note that the term “package” in this context is being used to describe a bundle of software to be installed (i.e. as a synonym for a distribution ). It does not to refer to the kind of package that you import in your Python source code (i.e. a container of modules). It is common in the Python community to refer to a distribution using the term “package”. Using the term “distribution” is often not preferred, because it can easily be confused with a Linux distribution, or another larger software distribution like Python itself.

Requirements for Installing Packages¶

This section describes the steps to follow before installing other Python packages.

Ensure you can run Python from the command line¶

Before you go any further, make sure you have Python and that the expected version is available from your command line. You can check this by running:

If you’re a newcomer and you get an error like this:

It’s because this command and other suggested commands in this tutorial are intended to be run in a shell (also called a terminal or console). See the Python for Beginners getting started tutorial for an introduction to using your operating system’s shell and interacting with Python.

It’s recommended to write rather than plain python in order to ensure that commands are run in the Python installation matching the currently running notebook (which may not be the same Python installation that the python command refers to).

Ensure you can run pip from the command line¶

Additionally, you’ll need to make sure you have pip available. You can check this by running:

If pip isn’t already installed, then first try to bootstrap it from the standard library:

Ensure pip, setuptools, and wheel are up to date¶

While pip alone is sufficient to install from pre-built binary archives, up to date copies of the setuptools and wheel projects are useful to ensure you can also install from source archives:

Optionally, create a virtual environment¶

See section below for details, but here’s the basic venv 3 command to use on a typical Linux system:

This will create a new virtual environment in the tutorial_env subdirectory, and configure the current shell to use it as the default python environment.

Creating Virtual Environments¶

Imagine you have an application that needs version 1 of LibFoo, but another application requires version 2. How can you use both these applications? If you install everything into /usr/lib/python3.6/site-packages (or whatever your platform’s standard location is), it’s easy to end up in a situation where you unintentionally upgrade an application that shouldn’t be upgraded.

Or more generally, what if you want to install an application and leave it be? If an application works, any change in its libraries or the versions of those libraries can break the application.

Also, what if you can’t install packages into the global site-packages directory? For instance, on a shared host.

In all these cases, virtual environments can help you. They have their own installation directories and they don’t share libraries with other virtual environments.

Currently, there are two common tools for creating Python virtual environments:

venv is available by default in Python 3.3 and later, and installs pip and setuptools into created virtual environments in Python 3.4 and later.

Requirements txt python как установить

pip is a command line program. When you install pip, a pip command is added to your system, which can be run from the command prompt as follows:

pip supports installing from PyPI, version control, local projects, and directly from distribution files.

The most common scenario is to install from PyPI using :ref:`Requirement Specifiers`

For more information and examples, see the :ref:`pip install` reference.

Basic Authentication Credentials

Using a Proxy Server

When installing packages from PyPI, pip requires internet access, which in many corporate environments requires an outbound HTTP proxy server.

pip can be configured to connect through a proxy server in various ways:

«Requirements files» are files containing a list of items to be installed using :ref:`pip install` like so:

Logically, a Requirements file is just a list of :ref:`pip install` arguments placed in a file. Note that you should not rely on the items in the file being installed by pip in any particular order.

In practice, there are 4 common uses of Requirements files:

If SomeDependency was previously a top-level requirement in your requirements file, then replace that line with the new line. If SomeDependency is a sub-dependency, then add the new line.

It’s important to be clear that pip determines package dependencies using install_requires metadata, not by discovering requirements.txt files embedded in projects.

Use a constraints file like so:

Constraints files are used for exactly the same reason as requirements files when you don’t know exactly what things you want to install. For instance, say that the «helloworld» package doesn’t work in your environment, so you have a local patched version. Some things you install depend on «helloworld», and some don’t.

One way to ensure that the patched version is used consistently is to manually audit the dependencies of everything you install, and if «helloworld» is present, write a requirements file to use when installing that thing.

Constraints files offer a better way: write a single constraints file for your organisation and use that everywhere. If the thing being installed requires «helloworld» to be installed, your fixed version specified in your constraints file will be used.

Constraints file support was added in pip 7.1. In :ref:`Resolver changes 2020` we did a fairly comprehensive overhaul, removing several undocumented and unsupported quirks from the previous implementation, and stripped constraints files down to being purely a way to specify global (version) limits for packages.

Installing from Wheels

If no satisfactory wheels are found, pip will default to finding source archives.

To install directly from a wheel archive:

To include optional dependencies provided in the provides_extras metadata in the wheel, you must add quotes around the install target name:

In the future, the path[extras] syntax may become deprecated. It is recommended to use PEP 508 syntax wherever possible.

For the cases where wheels are not available, pip offers :ref:`pip wheel` as a convenience, to build wheels for all your requirements and dependencies.

:ref:`pip wheel` requires the wheel package to be installed, which provides the «bdist_wheel» setuptools extension that it uses.

To build wheels for your requirements and all their dependencies to a local directory:

And then to install those requirements just using your local directory of wheels (and not from PyPI):

pip is able to uninstall most packages like so:

pip also performs an automatic uninstall of an old version of a package before upgrading to a newer version.

For more information and examples, see the :ref:`pip uninstall` reference.

To list installed packages:

To list outdated packages, and show the latest version available:

To show details about an installed package:

For more information and examples, see the :ref:`pip list` and :ref:`pip show` reference pages.

Searching for Packages

pip can search PyPI for packages using the pip search command:

The query will be used to search the names and summaries of all packages.

For more information and examples, see the :ref:`pip search` reference.

pip comes with support for command line completion in bash, zsh and fish.

To setup for powershell:

Alternatively, you can use the result of the completion command directly with the eval function of your shell, e.g. by adding the following to your startup file:

Installing from local packages

In some cases, you may want to install from local packages only, with no traffic to PyPI.

First, download the archives that fulfill your requirements:

Note that pip download will look in your wheel cache first, before trying to download from PyPI. If you’ve never installed your requirements before, you won’t have a wheel cache for those items. In that case, if some of your requirements don’t come as wheels from PyPI, and you want wheels, then run this instead:

Then, to install from local only, you’ll be using :ref:`—find-links ` and :ref:`—no-index ` like so:

«Only if needed» Recursive Upgrade

As an historic note, an earlier «fix» for getting the only-if-needed behaviour was:

A proposal for an upgrade-all command is being considered as a safer alternative to the behaviour of eager upgrading.

To install «SomePackage» into an environment with site.USER_BASE customized to ‘/myappenv’, do the following:

To make the rules clearer, here are some examples:

From within a real python, where SomePackage is not installed globally:

From within a real python, where SomePackage is installed globally, but is not the latest version:

From within a real python, where SomePackage is installed globally, and is the latest version:

Fixing conflicting dependencies

Using pip from your program

What this means in practice is that everything inside of pip is considered an implementation detail. Even the fact that the import name is pip is subject to change without notice. While we do try not to break things as much as possible, all the internal APIs can change at any time, for any reason. It also means that we generally won’t fix issues that are a result of using pip in an unsupported way.

It should also be noted that installing packages into sys.path in a running Python process is something that should only be done with care. The import system caches certain data, and installing new packages while a program is running may not always behave as expected. In practice, there is rarely an issue, but it is something to be aware of.

Having said all of the above, it is worth covering the options available if you decide that you do want to run pip from within your program. The most reliable approach, and the one that is fully supported, is to run pip in a subprocess. This is easily done using the standard subprocess module:

If you want to process the output further, use one of the other APIs in the module. We are using freeze here which outputs installed packages in requirements format.:

If you don’t want to use pip’s command line functionality, but are rather trying to implement code that works with Python packages, their metadata, or PyPI, then you should consider other, supported, packages that offer this type of ability. Some examples that you could consider include:

Changes to the pip dependency resolver in 20.3 (2020)

pip 20.3 has a new dependency resolver, on by default for Python 3 users. (pip 20.1 and 20.2 included pre-release versions of the new dependency resolver, hidden behind optional user flags.) Read below for a migration guide, how to invoke the legacy resolver, and the deprecation timeline. We also made a two-minute video explanation you can watch.

We will continue to improve the pip dependency resolver in response to testers’ feedback. Please give us feedback through the resolver testing survey.

The big change in this release is to the pip dependency resolver within pip.

The most significant changes to the resolver are:

So, if you have been using workarounds to force pip to deal with incompatible or inconsistent requirements combinations, now’s a good time to fix the underlying problem in the packages, because pip will be stricter from here on out.

Per our :ref:`Python 2 Support` policy, pip 20.3 users who are using Python 2 will use the legacy resolver by default. Python 2 users should upgrade to Python 3 as soon as possible, since in pip 21.0 in January 2021, pip dropped support for Python 2 altogether.

How to upgrade and migrate

Test the new version of pip.

While we have tried to make sure that pip’s test suite covers as many cases as we can, we are very aware that there are people using pip with many different workflows and build processes, and we will not be able to cover all of those without your help.

Troubleshoot and try these workarounds if necessary.

Please report bugs through the resolver testing survey.

Setups to test with special attention

Specific things we’d love to get feedback on:

Please let us know through the resolver testing survey.

We plan for the resolver changeover to proceed as follows, using :ref:`Feature Flags` and following our :ref:`Release Cadence` :

Context and followup

As discussed in our announcement on the PSF blog, the pip team are in the process of developing a new «dependency resolver» (the part of pip that works out what to install based on your requirements).

We’re tracking our rollout in :issue:`6536` and you can watch for announcements on the low-traffic packaging announcements list and the official Python blog.

Using system trust stores for verifying HTTPS

pip 22.2 added experimental support for using system trust stores to verify HTTPS certificates instead of certifi. Using system trust stores has advantages over certifi like automatically supporting corporate proxy certificates without additional configuration.

In order to use system trust stores you must be using Python 3.10+ and install the package truststore from PyPI.

When to use system trust stores

You should try using system trust stores when there is a custom certificate chain configured for your system that pip isn’t aware of. Typically this situation will manifest with an SSLCertVerificationError with the message «certificate verify failed: unable to get local issuer certificate»:

This error means that OpenSSL wasn’t able to find a trust anchor to verify the chain against. Using system trust stores instead of certifi will likely solve this issue.

If you encounter a TLS/SSL error when using the truststore feature you should open an issue on the truststore GitHub issue tracker instead of pip’s issue tracker. The maintainers of truststore will help diagnose and fix the issue.

Менеджер пакетов pip

Введение

pip — система управления пакетами, которая используется для установки и управления программными пакетами, написанными на Python.

Терминология

Примеры

Установка пакетов

Установка пакета из PyPI

Установка пакета из локального файла wheel

Установка пакета из Git репозитория

Установка пакета из директории

Удаление пакетов

Чтобы удалить пакет:

Список установленных пакетов

Вывод списка пакетов, установленных через pip

Пакеты обновления

обновит пакет SomePackage и все его зависимости. Кроме того, pip автоматически удаляет старую версию пакета перед обновлением.

Чтобы обновить сам пункт, сделайте

на машинах Windows.

Обновление всех устаревших пакетов в Linux

Обновление всех устаревших пакетов в Windows

Создайте файл require.txt для всех пакетов в системе

pip помогает в создании requirements.txt файлов, предоставляя freeze опцию.

Создайте файл require.txt из пакетов только в текущем virtualenv

pip помогает в создании requirements.txt файлов, предоставляя freeze опцию.

—local параметр будет выводить только список пакетов и версий, которые установлены локально на virtualenv. Глобальные пакеты не будут перечислены.

Использование определенной версии Python с pip

Если у вас установлены и Python 3, и Python 2, вы можете указать, какую версию Python вы бы хотели использовать в pip. Это полезно, когда пакеты поддерживают только Python 2 или 3 или когда вы хотите протестировать оба.

Если вы хотите установить пакеты для Python 2, запустите:

Если вы хотите установить пакеты для Python 3, выполните:

Вы также можете запустить установку пакета для конкретной установки Python с помощью:

На платформах OS-X / Linux / Unix важно помнить о различии между системной версией python (обновление которой делает вашу систему неработоспособной) и пользовательской версией (версиями) python. Вы можете, в зависимости от которого вы пытаетесь обновить, необходимо префикс эти команды с sudo и ввода пароля.

Установка пакетов еще не на пипе, как колеса

Многие чистые пакеты python еще не доступны в индексе пакетов Python в виде колес, но все равно устанавливаются нормально. Однако некоторые пакеты в Windows выдают ужасную ошибку vcvarsall.bat not found.

Кроме того, вам нужно получить соответствующий комплект разработки для Windows для используемой версии python, заголовки для любой библиотеки, к которой интерфейс пытается подключить пакет, возможно, заголовки python для версии python и т. Д.

Python 2.7 использовал Visual Studio 2008, Python 3.3 и 3.4 использовал Visual Studio 2010, а Python 3.5+ использует Visual Studio 2015.

Примечание по установке предварительных выпусков

Замечание по установке версий разработки

Для таких установок существует три варианта:

Синтаксис

Параметры

Примечания

При необходимости, pip выполняет компиляцию нативного кода. В Linux Python автоматически выберет доступный компилятор C в вашей системе.

Менеджер пакетов PIP. Гайд по использованию

P IP — это менеджер пакетов. Он позволяет устанавливать и управлять пакетами на Python.

Представьте себе ситуацию: вы собираете проект и подключаете множество сторонних библиотек для реализации своей задачи. Если это делать вручную, процесс выглядит примерно так:

Вполне вероятно, что эта версия библиотеки вообще не подходит, и весь процесс повторяется заново. А если таких библиотек 10? Устанавливать их вручную?

Если вы работали с другими языками программирования, концепция pip может показаться вам знакомой. Pip похож на npm (в Javascript), composer (в PHP) или gem (в Ruby).

Pip является стандартным менеджером пакетов в Python

Pip или pip3?

В зависимости от того, какая версия Python установлена в системе, может потребоваться использовать pip3 вместо pip.

Если вы не знаете какая версия Python установлена на вашей системе, выполните следующие команды:

Советуем использовать версию Python 3.6 и выше

Если команда «python» не найдена, установите Python по инструкции из предыдущей статьи.

Далее нужно убедиться, что сам PIP установлен и работает корректно. Узнать это поможет команда:

Команда отобразит в консоли версию pip, путь до pip и версию python, для которой в дальнейшем будут устанавливаться пакеты:

pip 19.2.3 from /usr/local/lib/python3.8/site-packages/pip (python 3.8)

Альтернативный вариант вызова pip:

Если pip не установлен

Pip поставляется вместе с Python, и доступен после его установки. Если по какой-то причине pip не установлен на вашей системе, установить его будет не сложно.

Windows

Linux (Ubuntu и Debian)

Для Питона 2-й версии, выполните команду:

apt-get install python-pip

Для Питона 3-ей версии:

apt-get install python3-pip

MacOS

Должна появиться запись Successfully Installed. Процесс закончен, можно приступать к работе с PIP на MacOS!

Как обновить PIP

Иногда, при установке очередного пакета, можно видеть сообщение о том, что доступна новая версия pip.

WARNING: You are using pip version 19.2.3, however version 19.3.1 is available.

А в следующей за ней строке

указана команда для обновления pip:

Команды PIP

Синтаксис pip выглядит следующим образом: pip + команда + доп. опции

Рассмотрим команды pip:

Пример работы с пакетами

PIP позволяет устанавливать, обновлять и удалять пакеты на компьютере. Ниже попробуем разобраться с работой менеджера pip на примере парсинга названий свежих статей на сайте habr.com.

Для начала, нам необходимо установить beautifulsoup4 — библиотеку для парсинга информации с веб-сайтов.

pip3 install beautifulsoup4

pip3 install beautifulsoup4==4.8.2

Данная команда способна даже перезаписать текущую версию на ту, что вы укажите.

Также для работы beautifulsoup нам понадобится пакет lxml :

☝️ Важный момент : по умолчанию pip устанавливает пакеты глобально. Это может привести к конфликтам между версиями пакетов. На практике, чтобы изолировать пакеты текущего проекта, создают виртуальное окружение (virtualenv).

Шаг #2 Импортирование в скрипте.

Для того чтобы воспользоваться функционалом установленного пакета, подключим его в наш скрипт, и напишем простой парсер:

from urllib.request import urlopen from bs4 import BeautifulSoup # скачиваем html page = urlopen(«https://habr.com/ru/top/») content = page.read() # сохраняем html в виде объекта BeautifulSoup soup = BeautifulSoup(content, «lxml») # Находим все теги «a» с классом «post__title_link» all_a_titles = soup.findAll(«a», < "class" : "post__title_link" >) # Проходим по каждому найденному тегу и выводим на экран название статьи for a_title in all_a_titles: print(a_title.text)

Шаг #3 requirements.txt.

Файл requirements.txt создается командой:

pip freeze > requirements.txt

и выглядит следующим образом:

beautifulsoup4==4.8.2 lxml==4.4.2 soupsieve==1.9.5

Теперь ваш скрипт вместе с файлом requirements.txt можно сохранить в системе контроля версий (например git).

Для работы парсера в новом месте (например на компьютере другого разработчика или на удаленном сервере) необходимо затянуть файлы из системы контроля версий и выполнить команду:

Шаг #4 Обновление/удаление установленных пакетов.

Однако бывают ситуации, когда нужно обновить сразу все пакеты из requirements.txt. Достаточно выполнить команду:

Для удаления пакета выполните:

pip uninstall package-name

Для удаления всех пакетов из requirements.txt:

Мы разобрали основы по работе с PIP. Как правило, этого достаточно для работы с большей частью проектов.

Setting Up Your Python Environment With Venv and requirements.txt

This post is part of my Python 101 series:

By default, all the Python packages you install on your computer are used within all of your projects. But, what if one project requires version 1 of a package and another project requires version 2?

Or, if you have multiple people working on a project, how do you tell them which dependencies are needed and make sure everyone is using the same versions?

This is where using requirements.txt and virtual environments come in.

What Is requirements.txt?

When you usually install a package, you probably do something like:

pip install pandas

But, imagine if you have someone else working on the project and they also install pandas. Or, maybe you are deploying your project to Netlify or are using Docker. How do you make sure the right dependencies get installed and the correct version?

With requirements.txt, you can list all the required packages for your project and what version is needed. If you are familiar with NPM or Composer, you may have seen a similar concept in their package.json or composer.json files.

Creating Your requirements.txt

In your project, you can create a requirements.txt file. Inside, you can list each package that is needed.

To make it easy to scan and read, the list is normally alphabetical. If you want a specific version, you could add an equal sign like this:

Now, it would be challenging to manually write out all your dependencies and remember to change the version number when you upgrade. Luckily, pip can help with this.

Even better, you can use pip freeze > requirements.txt to automatically take this list and store it in your requirements.txt file.

As you add, update, and remove packages, you can run that command again to update your requirements.txt file.

Installing From Your requirements.txt

Let’s say you just cloned a git repo. This repo contains a requirements.txt file. What do you do next?

Using Virtual Environments

Now, if you only have one Python project on your computer, this may be fine as-is. But, what if you start cloning or creating several projects all with their own requirements.txt files? You can quickly end up with package versions that are not compatible with each other.

This is where virtual environments come in. You can set up your project to exist within its own environment and packages only installed within that environment. Each project will have its own environment and its own packages installed within it.

To create your virtual environment, go into your project and run:

Once the command is finished, your virtual environment will be ready. Next, you can «activate» it by running the activation script.

Once activated, you will see the name of the environment within the terminal.

Now, you will be able to install packages and run Python within the environment without interfering with packages installed globally.

Once you are finished, just use the deactivate command to exit the virtual environment.

Python Dev Environment Part 3: dependencies with install_requires and requirements.txt

In Part 1 of this series, we created a simple Python distribution package called «pygreet.» In Part 2, we wrote tests and ran them using pytest.

Other than pytest, we did not install anything that wasn’t already included in the Python standard library. Often, though, a package will have several dependencies. How do we best handle these?

Let’s explore further.

Add a function with a dependency

Take the pygreet package we have been building and add a friendly time-telling function.

Exit fullscreen mode

We have added two things: import arrow and the greet_city function, which takes a timezone as input.

Include list of dependencies in install_requires in setup.py

Because arrow is an external dependency, let’s add it to setup.py :

Exit fullscreen mode

(Re-)installing package also installs dependencies

Once this is saved, installing our package again (in editable mode, just as before) should bring in arrow and its dependencies.

Exit fullscreen mode

The output should include «Successfully installed arrow. » and other packages, with version numbers.

We cannot forget to write a test for our new function. In the tests directory, a new file called test_greet_city.py contains:

Exit fullscreen mode

Run pytest in the current directory. Feel proud.

Development dependencies

Such as pytest. Of course, if you are installing the development dependencies you need, then you will also want the actual package you are building to be installed as well. So, let’s add both in a requirements.txt file:

Exit fullscreen mode

You can run this file with:

Exit fullscreen mode

Exit fullscreen mode

Your source code tree should look something like this now:

Exit fullscreen mode

The next time you are on a fresh system, you can download/checkout/pull your Python code, setup your virtual environment, pip install your requirements, and keep coding.

Versions and upgrading

I have chosen not to specify versions of each package, or upper/lower bounds for version numbers. This way, at any time, I can

Exit fullscreen mode

And upgrade all the packages. This works great, unless I am not paying attention to breaking API changes in any of the dependent packages. If that happens, there will be pain.

You might also try pip freeze to see package versions. You may use the pip freeze output to create a requirements.txt file with pinned versions. That way, there will be no surprises, although your packages will grow out of date and insecure unless you update the versions.

This series is introductory in nature, and I hope you find it helpful. Please continue to explore, and enjoy, Python packaging and dependency management!