sysconfig --- 提供 Python 設定資訊的存取

在 3.2 版被加入.

原始碼:Lib/sysconfig


The sysconfig module provides access to Python's configuration information like the list of installation paths and the configuration variables relevant for the current platform.

Configuration variables

A Python distribution contains a Makefile and a pyconfig.h header file that are necessary to build both the Python binary itself and third-party C extensions compiled using setuptools.

sysconfig puts all variables found in these files in a dictionary that can be accessed using get_config_vars() or get_config_var().

Notice that on Windows, it's a much smaller set.

sysconfig.get_config_vars(*args)

With no arguments, return a dictionary of all configuration variables relevant for the current platform.

With arguments, return a list of values that result from looking up each argument in the configuration variable dictionary.

For each argument, if the value is not found, return None.

sysconfig.get_config_var(name)

Return the value of a single variable name. Equivalent to get_config_vars().get(name).

If name is not found, return None.

用法範例:

>>> import sysconfig
>>> sysconfig.get_config_var('Py_ENABLE_SHARED')
0
>>> sysconfig.get_config_var('LIBDIR')
'/usr/local/lib'
>>> sysconfig.get_config_vars('AR', 'CXX')
['ar', 'g++']

Installation paths

Python uses an installation scheme that differs depending on the platform and on the installation options. These schemes are stored in sysconfig under unique identifiers based on the value returned by os.name. The schemes are used by package installers to determine where to copy files to.

Python currently supports nine schemes:

  • posix_prefix: scheme for POSIX platforms like Linux or macOS. This is the default scheme used when Python or a component is installed.

  • posix_home: scheme for POSIX platforms, when the home option is used. This scheme defines paths located under a specific home prefix.

  • posix_user: scheme for POSIX platforms, when the user option is used. This scheme defines paths located under the user's home directory (site.USER_BASE).

  • posix_venv: scheme for Python virtual environments on POSIX platforms; by default it is the same as posix_prefix.

  • nt: scheme for Windows. This is the default scheme used when Python or a component is installed.

  • nt_user: scheme for Windows, when the user option is used.

  • nt_venv: scheme for Python virtual environments on Windows; by default it is the same as nt.

  • venv: a scheme with values from either posix_venv or nt_venv depending on the platform Python runs on.

  • osx_framework_user: scheme for macOS, when the user option is used.

Each scheme is itself composed of a series of paths and each path has a unique identifier. Python currently uses eight paths:

  • stdlib: directory containing the standard Python library files that are not platform-specific.

  • platstdlib: directory containing the standard Python library files that are platform-specific.

  • platlib: directory for site-specific, platform-specific files.

  • purelib: directory for site-specific, non-platform-specific files ('pure' Python).

  • include: directory for non-platform-specific header files for the Python C-API.

  • platinclude: directory for platform-specific header files for the Python C-API.

  • scripts: directory for script files.

  • data: directory for data files.

User scheme

This scheme is designed to be the most convenient solution for users that don't have write permission to the global site-packages directory or don't want to install into it.

Files will be installed into subdirectories of site.USER_BASE (written as userbase hereafter). This scheme installs pure Python modules and extension modules in the same location (also known as site.USER_SITE).

posix_user

Path

Installation directory

stdlib

userbase/lib/pythonX.Y

platstdlib

userbase/lib/pythonX.Y

platlib

userbase/lib/pythonX.Y/site-packages

purelib

userbase/lib/pythonX.Y/site-packages

include

userbase/include/pythonX.Y

scripts

userbase/bin

data

userbase

nt_user

Path

Installation directory

stdlib

userbase\PythonXY

platstdlib

userbase\PythonXY

platlib

userbase\PythonXY\site-packages

purelib

userbase\PythonXY\site-packages

include

userbase\PythonXY\Include

scripts

userbase\PythonXY\Scripts

data

userbase

osx_framework_user

Path

Installation directory

stdlib

userbase/lib/python

platstdlib

userbase/lib/python

platlib

userbase/lib/python/site-packages

purelib

userbase/lib/python/site-packages

include

userbase/include/pythonX.Y

scripts

userbase/bin

data

userbase

Home scheme

The idea behind the "home scheme" is that you build and maintain a personal stash of Python modules. This scheme's name is derived from the idea of a "home" directory on Unix, since it's not unusual for a Unix user to make their home directory have a layout similar to /usr/ or /usr/local/. This scheme can be used by anyone, regardless of the operating system they are installing for.

posix_home

Path

Installation directory

stdlib

home/lib/python

platstdlib

home/lib/python

platlib

home/lib/python

purelib

home/lib/python

include

home/include/python

platinclude

home/include/python

scripts

home/bin

data

home

Prefix scheme

The "prefix scheme" is useful when you wish to use one Python installation to perform the build/install (i.e., to run the setup script), but install modules into the third-party module directory of a different Python installation (or something that looks like a different Python installation). If this sounds a trifle unusual, it is---that's why the user and home schemes come before. However, there are at least two known cases where the prefix scheme will be useful.

First, consider that many Linux distributions put Python in /usr, rather than the more traditional /usr/local. This is entirely appropriate, since in those cases Python is part of "the system" rather than a local add-on. However, if you are installing Python modules from source, you probably want them to go in /usr/local/lib/python2.X rather than /usr/lib/python2.X.

Another possibility is a network filesystem where the name used to write to a remote directory is different from the name used to read it: for example, the Python interpreter accessed as /usr/local/bin/python might search for modules in /usr/local/lib/python2.X, but those modules would have to be installed to, say, /mnt/@server/export/lib/python2.X.

posix_prefix

Path

Installation directory

stdlib