Python site packages path linux

Lee On Coding

My blog about coding and stuff.

How does python find packages?

I just ran into a situation where I compiled and installed Python 2.7.9 from source on Ubuntu, but Python could not find the packages I had previously installed. This naturally raises the question — how does Python know where to find packages when you call import ? This post applies specifically to Python 2.7.9, but I’m guessing Python 3x works very similarly.

In this post I first describe how Python finds packages, and then I’ll finish with the discovery I made regarding the default Python that ships with Ubuntu and how it differs from vanilla Python in how it finds packages.

sys.path

Python imports work by searching the directories listed in sys.path .

Using my default Ubuntu 14.04 Python:

So Python will find any packages that have been installed to those locations.

How sys.path gets populated

As the docs explain, sys.path is populated using the current working directory, followed by directories listed in your PYTHONPATH environment variable, followed by installation-dependent default paths, which are controlled by the site module.

You can read more about sys.path in the Python docs.

Assuming your PYTHONPATH environment variable is not set, sys.path will consist of the current working directory plus any manipulations made to it by the site module.

The site module is automatically imported when you start Python, you can read more about how it manipulates your sys.path in the Python docs.

It’s a bit involved.

You can manipulate sys.path

You can manipulate sys.path during a Python session and this will change how Python finds modules. For example:

The module __file__ attribute

When you import a module, you usually can check the __file__ attribute of the module to see where the module is in your filesystem:

However, the Python docs state that:

The file attribute is not present for C modules that are statically linked into the interpreter; for extension modules loaded dynamically from a shared library, it is the pathname of the shared library file.

So, for example this doesn’t work:

It makes sense that the sys module is statically linked to the interpreter — it is essentially part of the interpreter!

The imp module

Python exposes the entire import system through the imp module. That’s pretty cool that all of this stuff is exposed for us to abuse, if we wanted to.

imp.find_module can be used to find a module:

You can also import and arbitrary Python source as a module using imp.load_source . This is the same example before, except imports our module using imp instead of by manipulating sys.path :

Passing ‘hi’ to imp.load_source simply sets the __name__ attribute of the module.

Ubuntu Python

Now back to the issue of missing packages after installing a new version of Python compiled from source. By comparing the sys.path from both the Ubuntu Python, which resides at /usr/bin/python , and the newly installed Python, which resides at /usr/local/bin/python , I could sort things out:

Ubuntu Python ( /usr/bin/python ):

Python compiled from source ( /usr/local/bin/python )

Turns out what mattered for me was dist-packages vs. site-packages . Using Ubuntu’s Python, my packages were installed to /usr/local/lib/python2.7/dist-packages , whereas the new Python I installed expects packages to be installed to /usr/local/lib/python2.7/site-packages . I just had to manipulate the PYTHONPATH environment variable to point to dist-packages in order to gain access to the previously installed packaged with the newly installed version of Python.

How did Ubuntu manipulate the sys.path ?

So how does the Ubuntu distribution of Python know to use /usr/local/lib/python2.7/dist-packages in sys.path ? It’s hardcoded into their site module! First, find where the site module code lives:

Here is an excerpt from Ubuntu Python’s site.py , which I peeked by opening /usr/lib/python2.7/site.py in a text editor. First, a comment at the top:

For Debian and derivatives, this sys.path is augmented with directories for packages distributed within the distribution. Local addons go into /usr/local/lib/python /dist-packages, Debian addons install into /usr//python /dist-packages. /usr/lib/python /site-packages is not used.

OK so there you have it. They explain how the Debian distribution of Python is different.

And now, for the code that implementes this change:

It’s all there, if you are crazy enough to dig this deep.

© Lee Mendelowitz – Built with Pure Theme for Pelican

Источник

site — Site-specific configuration hook¶

Source code: Lib/site.py

This module is automatically imported during initialization. The automatic import can be suppressed using the interpreter’s -S option.

Importing this module will append site-specific paths to the module search path and add a few builtins, unless -S was used. In that case, this module can be safely imported with no automatic modifications to the module search path or additions to the builtins. To explicitly trigger the usual site-specific additions, call the site.main() function.

Changed in version 3.3: Importing the module used to trigger paths manipulation even when using -S .

It starts by constructing up to four directories from a head and a tail part. For the head part, it uses sys.prefix and sys.exec_prefix ; empty heads are skipped. For the tail part, it uses the empty string and then lib/site-packages (on Windows) or lib/python X.Y /site-packages (on Unix and macOS). For each of the distinct head-tail combinations, it sees if it refers to an existing directory, and if so, adds it to sys.path and also inspects the newly added path for configuration files.

Changed in version 3.5: Support for the “site-python” directory has been removed.

If a file named “pyvenv.cfg” exists one directory above sys.executable, sys.prefix and sys.exec_prefix are set to that directory and it is also checked for site-packages (sys.base_prefix and sys.base_exec_prefix will always be the “real” prefixes of the Python installation). If “pyvenv.cfg” (a bootstrap configuration file) contains the key “include-system-site-packages” set to anything other than “true” (case-insensitive), the system-level prefixes will not be searched for site-packages; otherwise they will.

A path configuration file is a file whose name has the form name .pth and exists in one of the four directories mentioned above; its contents are additional items (one per line) to be added to sys.path . Non-existing items are never added to sys.path , and no check is made that the item refers to a directory rather than a file. No item is added to sys.path more than once. Blank lines and lines beginning with # are skipped. Lines starting with import (followed by space or tab) are executed.

An executable line in a .pth file is run at every Python startup, regardless of whether a particular module is actually going to be used. Its impact should thus be kept to a minimum. The primary intended purpose of executable lines is to make the corresponding module(s) importable (load 3rd-party import hooks, adjust PATH etc). Any other initialization is supposed to be done upon a module’s actual import, if and when it happens. Limiting a code chunk to a single line is a deliberate measure to discourage putting anything more complex here.

Источник

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:

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:

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:

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

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.

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:

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¶

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

Источник

Как найти расположение моего каталога Python site-packages?

Как найти расположение каталога мой сайт-пакеты?

17 ответов:

существует два типа каталогов site-packages,глобальные и для каждого пользователя.

глобальные site-packages (» dist-packages») каталоги перечислены в sys.path при запуске:

для более краткого списка выполнить getsitepackages С модуль сайта в коде Python:

Примечание: С virtualenvs getsitepackages is недоступно, sys.path сверху будет правильно указан каталог site-packages virtualenv.

The для каждого пользователя каталог site-packages (PEP 370) где Python устанавливает ваши локальные пакеты:

если это указывает на несуществующий каталог, проверьте состояние выхода Python и см. python -m site —help для объяснения.

подсказка: под управлением pip list —user или pip freeze —user дает вам список всех установленных для каждого пользователя сайт-пакеты.

(или просто первый пункт с site.getsitepackages()[0] )

С » Как установить Django » документация (хотя это полезно не только для установки Django) — выполните следующее из оболочки:

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

Он будет указывать вам!—1—>

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

на ubuntu, папка site-packages, содержащая пакеты, установленные через setup_tools\easy_install\pip, будет находиться в /usr/local/lib/pythonX.X/dist-packages

вторая папка, вероятно, более полезна, если случай использования связано с установкой или чтением исходного кода.

Если вы не используете Ubuntu, вы, вероятно, безопасно копируете первое поле кода в терминал.

Это то, что сработало для меня:

как уже отмечалось, distutils.sysconfig имеет соответствующие параметры:

. хотя по умолчанию site.py делает что-то немного более сырой, перефразировал ниже:

(он также добавляет $/lib/site-python и добавляет оба пути для sys.exec_prefix а также, если эта константа будет отличаться).

что сказал, каков контекст? Вы не должны возиться с вашим site-packages напрямую; setuptools/distutils будет работать для установки, и ваша программа может быть запущена в virtualenv, где ваш pythonpath полностью является локальным пользователем,поэтому он не должен предполагать использование системных пакетов сайта напрямую.

допустим, вы установили пакет ‘django’. импортируйте его и введите в dir(django). Он покажет вам все функции и атрибуты с этим модулем. Введите интерпретатор python —

вы можете сделать то же самое, если вы установили mercurial.

Это для снежного барса. Но я думаю, что это должно работать в целом.

собственные системные пакеты, установленные с установкой python в системах на основе Debian, можно найти по адресу :

в OSX — /Library/Python/2.7/site-packages

С помощью этого небольшого кода:

тем не менее, список пакетов, установленных через pip можно найти в :

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

Примечание: расположение может отличаться в зависимости от вашей ОС, как в OSX

все ответы (или: один и тот же ответ повторяется снова и снова) неадекватны. Что вы хотите сделать это:

в последней строке отображается установочный каталог. Не спрашивайте меня о windows или других дисках, но поскольку это тот же самый dir, который использует easy_install по умолчанию, это, вероятно, правильно везде, где работает easy_install (так, везде, даже Mac). Повеселись. Примечание: оригинальный код имеет много ругательств в оно.

боковое Примечание: предлагаемое решение ( distutils.sysconfig.get_python_lib() ) не работает, когда есть несколько каталогов site-packages (как рекомендовано в статье). Он будет возвращать только основной каталог site-packages.

увы, у меня нет лучшего решения. Python, похоже, не отслеживает каталоги site-packages, а только пакеты внутри них.

это работает для меня. Он получит вам как папки dist-packages, так и site-packages. Если папка не находится на пути Python, она не будет в любом случае, тебе это очень полезно.

выход (установка Ubuntu):

дополнительно к get_python_lib функция уже упоминалось: на некоторых платформах различные каталоги используются для конкретных модулей платформы (например: модули, которые требуют компиляции). Если вы пройдете plat_specific=True в функцию вы получаете пакеты сайта для конкретных пакетов платформы.

Это должно работать на всех дистрибутивах В и из виртуальной среды из-за его» низкотехнологичной » природы. Модуль ОС всегда находится в Родительском каталоге ‘site-packages’

чтобы изменить dir на сайт-пакеты dir я использую следующий псевдоним (на *Nix системах):

ответ на старый вопрос. Но для этого используйте ipython.

это даст следующий вывод о пакете imaplib —

современный способ stdlib использует sysconfig модуль, доступный в версии 2.7 и 3.2+. Python в настоящее время использует восемь дорожки (docs):

• stdlib: каталог, содержащий стандартные файлы библиотеки Python, которые не зависят от платформы.
• platstdlib: каталог, содержащий стандартные файлы библиотеки Python, которые зависят от платформы.
• platlib: каталог для специфичных для сайта и платформы файлов.
• purelib: каталог для специфичных для сайта, не связанных с платформой файлов.
• включить: каталог для файлов заголовков, не зависящих от платформы.
• platinclude: каталог для специфичных для платформы заголовочных файлов.
• скрипты каталог файлов скрипт.
• сведения каталог файлов данных.

в большинстве случаев пользователи, обнаруживающие этот вопрос, будут заинтересованы в пути «purelib» (in в некоторых случаях, вы можете быть заинтересованы в ‘platlib’ тоже). В отличие от принятого в настоящее время ответа, этот метод не должен плохо себя вести в зависимости от того, активирован ли virtualenv.

на системном уровне (это Python 3.7.0 на mac OS):

С a венв, ты получишь что-то вроде этого

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

Примечание: sysconfig (источник) не следует путать с distutils.sysconfig подмодуля (источник) упоминается в нескольких других ответах здесь. Это совершенно другой модуль, и ему не хватает

Я должен был сделать что-то немного другое для проекта, над которым я работал: найти относительные каталог site-packages относительно базового префикса установки. Если папка site-packages была в /usr/lib/python2.7/site-packages , Я хочу /lib/python2.7/site-packages часть. Я, по сути, столкнулся с системами, где site-packages был в /usr/lib64 , и принятый ответ не работал на этих системах.

подобно ответу мошенника, мое решение заглядывает глубоко в кишки Distutils, чтобы найти путь, который на самом деле передается внутри setup.py . Это была такая боль, чтобы понять, что я не хочу, чтобы кто-нибудь когда-нибудь думать с этим.

это должно печатать что-то вроде /Lib/site-packages или /lib/python3.6/site-packages .

Источник