Установка пакетов python локально

Local project installs#

You can install local projects by specifying the project path to pip:

$ python -m pip install path/to/SomeProject

$ python -m pip install path/to/SomeProject

C:> py -m pip install path/to/SomeProject

This will install the project into the Python that pip is associated with, in a manner similar to how it would actually be installed.

This is what should be used in CI system and for deployments, since it most closely mirrors how a package would get installed if you build a distribution and installed from it (because that’s exactly what it does).

Editable installs#

You can install local projects in “editable” mode:

$ python -m pip install -e path/to/SomeProject

$ python -m pip install -e path/to/SomeProject

C:> py -m pip install -e path/to/SomeProject

Editable installs allow you to install your project without copying any files. Instead, the files in the development directory are added to Python’s import path. This approach is well suited for development and is also known as a “development installation”.

With an editable install, you only need to perform a re-installation if you change the project metadata (eg: version, what scripts need to be generated etc). You will still need to run build commands when you need to perform a compilation for non-Python code in the project (eg: C extensions).

It is possible to see behaviour differences between regular installs vs editable installs. These differences depend on the build-backend, and you should check the build-backend documentation for the details. In case you distribute the project as a “distribution package”, users will see the behaviour of regular installs — thus, it is important to ensure that regular installs work correctly.

This is functionally the same as setuptools’ develop mode, and that’s precisely the mechanism used for setuptools-based projects.

There are two advantages over using setup.py develop directly:

• This works with non-setuptools build-backends as well.
• The “.egg-info” directory is created relative to the project path, when using pip. This is generally a better location than setuptools, which dumps it in the current working directory.

Build artifacts#

Changed in version 21.3: The project being installed is no longer copied to a temporary directory before invoking the build system, by default. A —use-deprecated=out-of-tree-build option is provided as a temporary fallback to aid user migrations.

Changed in version 22.1: The —use-deprecated=out-of-tree-build option has been removed.

When provided with a project that’s in a local directory, pip will invoke the build system “in place”. This behaviour has several consequences:

• Local project builds will now be significantly faster, for certain kinds of projects and on systems with slow I/O (eg: via network attached storage or overly aggressive antivirus software).
• Certain build backends (eg: setuptools ) will litter the project directory with secondary build artifacts (eg: .egg-info directories).
• Certain build backends (eg: setuptools ) may not be able to perform with parallel builds anymore, since they previously relied on the fact that pip invoked them in a separate directory for each build.

Specifically, the current machine’s filesystem.

Источник

Использование локальной директории с пакетами в Python уже сейчас

В Python 3.8 предлагается добавить альтернативу виртуальным окружениям — локальную директорию с пакетами PEP 582 Python local packages directory.

Данный PEP предлагает добавить в Python механизм автоматического обнаружения директории __pypackages__ и использовать её при импорте в качестве источника установленных пакетов. Директория __pypackages__ будет иметь больший приоритет при импорте, чем глобальные или пользовательские директории с пакетами. Это позволит исключить создание, активацию или деактивацию виртуальных окружений.

Вот так будет выглядеть в Python 3.8 структура пакета с использованием __pypackages__ :

foo __pypackages__ 3.8 lib bottle myscript.py

В статье я расскажу как использовать локальную директорию с пакетами не дожидаясь выхода Python 3.8.

В статье описан базовый пример, проверенный в Linux, Python 3.5. Для других платформ, возможно, понадобится внести изменения.

Установка пакетов в локальную директорию

Установка почти не отличается от обычной установки пакетов с помощью pip, за исключением дополнительной опции —target . В ней указываем полный или относительный путь до директории с локальными пакетами.

pip3 install --target="$PWD/__pypackages__/3.5/lib/" bar

$PWD — переменная с текущей рабочей директорией.

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

foo __pypackages__ 3.5 lib bar myscript.py

Версию Python и вложенные директории приходится указывать вручную.

Так же могут возникнуть проблемы, если нужно установить пакеты с бинарным кодом и под разные архитектуры. У меня таких пакетов не было, но как решение можно добавить еще архитектуру в структуру директорий.

Есть еще один способ установки пакетов в конкретную директорию :

pip3 install --ignore-installed --install-option="--prefix=$PWD/__pypackages__" --install-option="--no-compile" bar

Но нужно обязательно указывать полный путь до места установки и дерево директорий будет отличаться от предложенной в PEP 582:

foo __pypackages__ lib python3.5 site-packages bar myscript.py

Использование локальной директории с пакетами

После установки пакетов осталось указать интерпретатору где искать зависимости.

Для этого нужно внести в список sys.path путь до локальной директории с пакетами. Добавить путь достаточно в главный (загружаемый первым) модуль, в остальные добавлять не обязательно. После этого можно импортировать установленные локально пакеты.

import os import sys _PATH = '/__pypackages__/3.5/lib/' sys.path.insert(0, os.path.dirname(os.path.abspath(__file__)) + _PATH) import bar

Единственное условие — главный модуль должен быть на том же уровне вложенности, что и директория __pypackages__ .

Еще один способ указать Python, где искать пакеты — это выставить переменную окружения перед запуском скрипта.

PYTHONPATH="$PWD/__pypackages__/3.5/lib/:$PYTHONPATH" python3 ./myscript.py

Таким нехитрым способом можно добиться схожего с PEP 582 функционала уже сейчас.

Источник

Installing Packages¶

This section covers the basics of how to install Python 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:

You should get some output like Python 3.6.3 . If you do not have Python, please install the latest 3.x version from python.org or refer to the Installing Python section of the Hitchhiker’s Guide to Python.

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

>>> python3 --version Traceback (most recent call last): File "", line 1, in NameError: name 'python3' is not defined 

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.

If you’re using an enhanced shell like IPython or the Jupyter notebook, you can run system commands like those in this tutorial by prefacing them with a ! character:

In [1]: import sys ! --version Python 3.6.3

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).

Due to the way most Linux distributions are handling the Python 3 migration, Linux users using the system Python without creating a virtual environment first should replace the python command in this tutorial with python3 and the python -m pip command with python3 -m pip —user . Do not run any of the commands in this tutorial with sudo : if you get a permissions error, come back to the section on creating virtual environments, set one up, and then continue with the tutorial as written.

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 you installed Python from source, with an installer from python.org, or via Homebrew you should already have pip. If you’re on Linux and installed using your OS package manager, you may have to install pip separately, see Installing pip/setuptools/wheel with Linux Package Managers .

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

python3 -m ensurepip --default-pip

py -m ensurepip --default-pip

If that still doesn’t allow you to run python -m pip :

• Securely Download get-pip.py1
• Run python get-pip.py . 2 This will install or upgrade pip. Additionally, it will install setuptools and wheel if they’re not installed already.

Warning Be cautious if you’re using a Python install that’s managed by your operating system or another package manager. get-pip.py does not coordinate with those tools, and may leave your system in an inconsistent state. You can use python get-pip.py —prefix=/usr/local/ to install in /usr/local which is designed for locally-installed software.

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:

python3 -m pip install --upgrade pip setuptools wheel

py -m pip install --upgrade pip setuptools wheel

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:

python3 -m venv tutorial_env source tutorial_env/bin/activate

py -m venv tutorial_env tutorial_env\Scripts\activate

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¶

Python “Virtual Environments” allow Python packages to be installed in an isolated location for a particular application, rather than being installed globally. If you are looking to safely install global command line tools, see Installing stand alone command line tools .

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.
• virtualenv needs to be installed separately, but supports Python 2.7+ and Python 3.3+, and pip , setuptools and wheel are always installed into created virtual environments by default (regardless of Python version).

The basic usage is like so:

python3 -m venv source /bin/activate

Источник