mirror of
				https://github.com/python/cpython.git
				synced 2025-10-31 13:41:24 +00:00 
			
		
		
		
	
		
			
				
	
	
		
			464 lines
		
	
	
	
		
			16 KiB
		
	
	
	
		
			ReStructuredText
		
	
	
	
	
	
			
		
		
	
	
			464 lines
		
	
	
	
		
			16 KiB
		
	
	
	
		
			ReStructuredText
		
	
	
	
	
	
| :mod:`!sysconfig` --- Provide access to Python's configuration information
 | |
| ==========================================================================
 | |
| 
 | |
| .. module:: sysconfig
 | |
|    :synopsis: Python's configuration information
 | |
| 
 | |
| .. moduleauthor:: Tarek Ziadé <tarek@ziade.org>
 | |
| .. sectionauthor:: Tarek Ziadé <tarek@ziade.org>
 | |
| 
 | |
| .. versionadded:: 3.2
 | |
| 
 | |
| **Source code:** :source:`Lib/sysconfig`
 | |
| 
 | |
| .. index::
 | |
|    single: configuration information
 | |
| 
 | |
| --------------
 | |
| 
 | |
| The :mod:`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 :file:`Makefile` and a :file:`pyconfig.h`
 | |
| header file that are necessary to build both the Python binary itself and
 | |
| third-party C extensions compiled using ``setuptools``.
 | |
| 
 | |
| :mod:`sysconfig` puts all variables found in these files in a dictionary that
 | |
| can be accessed using :func:`get_config_vars` or :func:`get_config_var`.
 | |
| 
 | |
| Notice that on Windows, it's a much smaller set.
 | |
| 
 | |
| .. function:: 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``.
 | |
| 
 | |
| 
 | |
| .. function:: 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``.
 | |
| 
 | |
| Example of usage::
 | |
| 
 | |
|    >>> 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:
 | |
| 
 | |
| Installation paths
 | |
| ------------------
 | |
| 
 | |
| Python uses an installation scheme that differs depending on the platform and on
 | |
| the installation options.  These schemes are stored in :mod:`sysconfig` under
 | |
| unique identifiers based on the value returned by :const:`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
 | |
|   (:const:`site.USER_BASE`).
 | |
| - *posix_venv*: scheme for :mod:`Python virtual environments <venv>` 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 :mod:`Python virtual environments <venv>` 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.
 | |
| 
 | |
| 
 | |
| .. _sysconfig-user-scheme:
 | |
| 
 | |
| 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 :const:`site.USER_BASE` (written
 | |
| as :file:`{userbase}` hereafter).  This scheme installs pure Python modules and
 | |
| extension modules in the same location (also known as :const:`site.USER_SITE`).
 | |
| 
 | |
| ``posix_user``
 | |
| ^^^^^^^^^^^^^^
 | |
| 
 | |
| ============== ===========================================================
 | |
| Path           Installation directory
 | |
| ============== ===========================================================
 | |
| *stdlib*       :file:`{userbase}/lib/python{X.Y}`
 | |
| *platstdlib*   :file:`{userbase}/lib/python{X.Y}`
 | |
| *platlib*      :file:`{userbase}/lib/python{X.Y}/site-packages`
 | |
| *purelib*      :file:`{userbase}/lib/python{X.Y}/site-packages`
 | |
| *include*      :file:`{userbase}/include/python{X.Y}`
 | |
| *scripts*      :file:`{userbase}/bin`
 | |
| *data*         :file:`{userbase}`
 | |
| ============== ===========================================================
 | |
| 
 | |
| ``nt_user``
 | |
| ^^^^^^^^^^^
 | |
| 
 | |
| ============== ===========================================================
 | |
| Path           Installation directory
 | |
| ============== ===========================================================
 | |
| *stdlib*       :file:`{userbase}\\Python{XY}`
 | |
| *platstdlib*   :file:`{userbase}\\Python{XY}`
 | |
| *platlib*      :file:`{userbase}\\Python{XY}\\site-packages`
 | |
| *purelib*      :file:`{userbase}\\Python{XY}\\site-packages`
 | |
| *include*      :file:`{userbase}\\Python{XY}\\Include`
 | |
| *scripts*      :file:`{userbase}\\Python{XY}\\Scripts`
 | |
| *data*         :file:`{userbase}`
 | |
| ============== ===========================================================
 | |
| 
 | |
| ``osx_framework_user``
 | |
| ^^^^^^^^^^^^^^^^^^^^^^
 | |
| 
 | |
| ============== ===========================================================
 | |
| Path           Installation directory
 | |
| ============== ===========================================================
 | |
| *stdlib*       :file:`{userbase}/lib/python`
 | |
| *platstdlib*   :file:`{userbase}/lib/python`
 | |
| *platlib*      :file:`{userbase}/lib/python/site-packages`
 | |
| *purelib*      :file:`{userbase}/lib/python/site-packages`
 | |
| *include*      :file:`{userbase}/include/python{X.Y}`
 | |
| *scripts*      :file:`{userbase}/bin`
 | |
| *data*         :file:`{userbase}`
 | |
| ============== ===========================================================
 | |
| 
 | |
| 
 | |
| .. _sysconfig-home-scheme:
 | |
| 
 | |
| 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 :file:`/usr/` or :file:`/usr/local/`.
 | |
| This scheme can be used by anyone, regardless of the operating system they
 | |
| are installing for.
 | |
| 
 | |
| ``posix_home``
 | |
| ^^^^^^^^^^^^^^
 | |
| 
 | |
| ============== ===========================================================
 | |
| Path           Installation directory
 | |
| ============== ===========================================================
 | |
| *stdlib*       :file:`{home}/lib/python`
 | |
| *platstdlib*   :file:`{home}/lib/python`
 | |
| *platlib*      :file:`{home}/lib/python`
 | |
| *purelib*      :file:`{home}/lib/python`
 | |
| *include*      :file:`{home}/include/python`
 | |
| *platinclude*  :file:`{home}/include/python`
 | |
| *scripts*      :file:`{home}/bin`
 | |
| *data*         :file:`{home}`
 | |
| ============== ===========================================================
 | |
| 
 | |
| 
 | |
| .. _sysconfig-prefix-scheme:
 | |
| 
 | |
| 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 :file:`/usr`, rather
 | |
| than the more traditional :file:`/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 :file:`/usr/local/lib/python2.{X}` rather than
 | |
| :file:`/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 :file:`/usr/local/bin/python` might search for
 | |
| modules in :file:`/usr/local/lib/python2.{X}`, but those modules would have to
 | |
| be installed to, say, :file:`/mnt/{@server}/export/lib/python2.{X}`.
 | |
| 
 | |
| ``posix_prefix``
 | |
| ^^^^^^^^^^^^^^^^
 | |
| 
 | |
| ============== ==========================================================
 | |
| Path           Installation directory
 | |
| ============== ==========================================================
 | |
| *stdlib*       :file:`{prefix}/lib/python{X.Y}`
 | |
| *platstdlib*   :file:`{prefix}/lib/python{X.Y}`
 | |
| *platlib*      :file:`{prefix}/lib/python{X.Y}/site-packages`
 | |
| *purelib*      :file:`{prefix}/lib/python{X.Y}/site-packages`
 | |
| *include*      :file:`{prefix}/include/python{X.Y}`
 | |
| *platinclude*  :file:`{prefix}/include/python{X.Y}`
 | |
| *scripts*      :file:`{prefix}/bin`
 | |
| *data*         :file:`{prefix}`
 | |
| ============== ==========================================================
 | |
| 
 | |
| ``nt``
 | |
| ^^^^^^
 | |
| 
 | |
| ============== ==========================================================
 | |
| Path           Installation directory
 | |
| ============== ==========================================================
 | |
| *stdlib*       :file:`{prefix}\\Lib`
 | |
| *platstdlib*   :file:`{prefix}\\Lib`
 | |
| *platlib*      :file:`{prefix}\\Lib\\site-packages`
 | |
| *purelib*      :file:`{prefix}\\Lib\\site-packages`
 | |
| *include*      :file:`{prefix}\\Include`
 | |
| *platinclude*  :file:`{prefix}\\Include`
 | |
| *scripts*      :file:`{prefix}\\Scripts`
 | |
| *data*         :file:`{prefix}`
 | |
| ============== ==========================================================
 | |
| 
 | |
| 
 | |
| Installation path functions
 | |
| ---------------------------
 | |
| 
 | |
| :mod:`sysconfig` provides some functions to determine these installation paths.
 | |
| 
 | |
| .. function:: get_scheme_names()
 | |
| 
 | |
|    Return a tuple containing all schemes currently supported in
 | |
|    :mod:`sysconfig`.
 | |
| 
 | |
| 
 | |
| .. function:: get_default_scheme()
 | |
| 
 | |
|    Return the default scheme name for the current platform.
 | |
| 
 | |
|    .. versionadded:: 3.10
 | |
|       This function was previously named ``_get_default_scheme()`` and
 | |
|       considered an implementation detail.
 | |
| 
 | |
|    .. versionchanged:: 3.11
 | |
|       When Python runs from a virtual environment,
 | |
|       the *venv* scheme is returned.
 | |
| 
 | |
| .. function:: get_preferred_scheme(key)
 | |
| 
 | |
|    Return a preferred scheme name for an installation layout specified by *key*.
 | |
| 
 | |
|    *key* must be either ``"prefix"``, ``"home"``, or ``"user"``.
 | |
| 
 | |
|    The return value is a scheme name listed in :func:`get_scheme_names`. It
 | |
|    can be passed to :mod:`sysconfig` functions that take a *scheme* argument,
 | |
|    such as :func:`get_paths`.
 | |
| 
 | |
|    .. versionadded:: 3.10
 | |
| 
 | |
|    .. versionchanged:: 3.11
 | |
|       When Python runs from a virtual environment and ``key="prefix"``,
 | |
|       the *venv* scheme is returned.
 | |
| 
 | |
| 
 | |
| .. function:: _get_preferred_schemes()
 | |
| 
 | |
|    Return a dict containing preferred scheme names on the current platform.
 | |
|    Python implementers and redistributors may add their preferred schemes to
 | |
|    the ``_INSTALL_SCHEMES`` module-level global value, and modify this function
 | |
|    to return those scheme names, to e.g. provide different schemes for system
 | |
|    and language package managers to use, so packages installed by either do not
 | |
|    mix with those by the other.
 | |
| 
 | |
|    End users should not use this function, but :func:`get_default_scheme` and
 | |
|    :func:`get_preferred_scheme` instead.
 | |
| 
 | |
|    .. versionadded:: 3.10
 | |
| 
 | |
| 
 | |
| .. function:: get_path_names()
 | |
| 
 | |
|    Return a tuple containing all path names currently supported in
 | |
|    :mod:`sysconfig`.
 | |
| 
 | |
| 
 | |
| .. function:: get_path(name, [scheme, [vars, [expand]]])
 | |
| 
 | |
|    Return an installation path corresponding to the path *name*, from the
 | |
|    install scheme named *scheme*.
 | |
| 
 | |
|    *name* has to be a value from the list returned by :func:`get_path_names`.
 | |
| 
 | |
|    :mod:`sysconfig` stores installation paths corresponding to each path name,
 | |
|    for each platform, with variables to be expanded.  For instance the *stdlib*
 | |
|    path for the *nt* scheme is: ``{base}/Lib``.
 | |
| 
 | |
|    :func:`get_path` will use the variables returned by :func:`get_config_vars`
 | |
|    to expand the path.  All variables have default values for each platform so
 | |
|    one may call this function and get the default value.
 | |
| 
 | |
|    If *scheme* is provided, it must be a value from the list returned by
 | |
|    :func:`get_scheme_names`.  Otherwise, the default scheme for the current
 | |
|    platform is used.
 | |
| 
 | |
|    If *vars* is provided, it must be a dictionary of variables that will update
 | |
|    the dictionary returned by :func:`get_config_vars`.
 | |
| 
 | |
|    If *expand* is set to ``False``, the path will not be expanded using the
 | |
|    variables.
 | |
| 
 | |
|    If *name* is not found, raise a :exc:`KeyError`.
 | |
| 
 | |
| 
 | |
| .. function:: get_paths([scheme, [vars, [expand]]])
 | |
| 
 | |
|    Return a dictionary containing all installation paths corresponding to an
 | |
|    installation scheme. See :func:`get_path` for more information.
 | |
| 
 | |
|    If *scheme* is not provided, will use the default scheme for the current
 | |
|    platform.
 | |
| 
 | |
|    If *vars* is provided, it must be a dictionary of variables that will
 | |
|    update the dictionary used to expand the paths.
 | |
| 
 | |
|    If *expand* is set to false, the paths will not be expanded.
 | |
| 
 | |
|    If *scheme* is not an existing scheme, :func:`get_paths` will raise a
 | |
|    :exc:`KeyError`.
 | |
| 
 | |
| 
 | |
| Other functions
 | |
| ---------------
 | |
| 
 | |
| .. function:: get_python_version()
 | |
| 
 | |
|    Return the ``MAJOR.MINOR`` Python version number as a string.  Similar to
 | |
|    ``'%d.%d' % sys.version_info[:2]``.
 | |
| 
 | |
| 
 | |
| .. function:: get_platform()
 | |
| 
 | |
|    Return a string that identifies the current platform.
 | |
| 
 | |
|    This is used mainly to distinguish platform-specific build directories and
 | |
|    platform-specific built distributions.  Typically includes the OS name and
 | |
|    version and the architecture (as supplied by :func:`os.uname`), although the
 | |
|    exact information included depends on the OS; e.g., on Linux, the kernel
 | |
|    version isn't particularly important.
 | |
| 
 | |
|    Examples of returned values:
 | |
| 
 | |
|    - linux-i586
 | |
|    - linux-alpha (?)
 | |
|    - solaris-2.6-sun4u
 | |
| 
 | |
|    Windows will return one of:
 | |
| 
 | |
|    - win-amd64 (64-bit Windows on AMD64, aka x86_64, Intel64, and EM64T)
 | |
|    - win-arm64 (64-bit Windows on ARM64, aka AArch64)
 | |
|    - win32 (all others - specifically, sys.platform is returned)
 | |
| 
 | |
|    macOS can return:
 | |
| 
 | |
|    - macosx-10.6-ppc
 | |
|    - macosx-10.4-ppc64
 | |
|    - macosx-10.3-i386
 | |
|    - macosx-10.4-fat
 | |
| 
 | |
|    For other non-POSIX platforms, currently just returns :data:`sys.platform`.
 | |
| 
 | |
| 
 | |
| .. function:: is_python_build()
 | |
| 
 | |
|    Return ``True`` if the running Python interpreter was built from source and
 | |
|    is being run from its built location, and not from a location resulting from
 | |
|    e.g. running ``make install`` or installing via a binary installer.
 | |
| 
 | |
| 
 | |
| .. function:: parse_config_h(fp[, vars])
 | |
| 
 | |
|    Parse a :file:`config.h`\-style file.
 | |
| 
 | |
|    *fp* is a file-like object pointing to the :file:`config.h`\-like file.
 | |
| 
 | |
|    A dictionary containing name/value pairs is returned.  If an optional
 | |
|    dictionary is passed in as the second argument, it is used instead of a new
 | |
|    dictionary, and updated with the values read in the file.
 | |
| 
 | |
| 
 | |
| .. function:: get_config_h_filename()
 | |
| 
 | |
|    Return the path of :file:`pyconfig.h`.
 | |
| 
 | |
| .. function:: get_makefile_filename()
 | |
| 
 | |
|    Return the path of :file:`Makefile`.
 | |
| 
 | |
| .. _sysconfig-cli:
 | |
| 
 | |
| Using :mod:`sysconfig` as a script
 | |
| ----------------------------------
 | |
| 
 | |
| You can use :mod:`sysconfig` as a script with Python's *-m* option:
 | |
| 
 | |
| .. code-block:: shell-session
 | |
| 
 | |
|     $ python -m sysconfig
 | |
|     Platform: "macosx-10.4-i386"
 | |
|     Python version: "3.2"
 | |
|     Current installation scheme: "posix_prefix"
 | |
| 
 | |
|     Paths:
 | |
|             data = "/usr/local"
 | |
|             include = "/Users/tarek/Dev/svn.python.org/py3k/Include"
 | |
|             platinclude = "."
 | |
|             platlib = "/usr/local/lib/python3.2/site-packages"
 | |
|             platstdlib = "/usr/local/lib/python3.2"
 | |
|             purelib = "/usr/local/lib/python3.2/site-packages"
 | |
|             scripts = "/usr/local/bin"
 | |
|             stdlib = "/usr/local/lib/python3.2"
 | |
| 
 | |
|     Variables:
 | |
|             AC_APPLE_UNIVERSAL_BUILD = "0"
 | |
|             AIX_GENUINE_CPLUSPLUS = "0"
 | |
|             AR = "ar"
 | |
|             ARFLAGS = "rc"
 | |
|             ...
 | |
| 
 | |
| This call will print in the standard output the information returned by
 | |
| :func:`get_platform`, :func:`get_python_version`, :func:`get_path` and
 | |
| :func:`get_config_vars`.
 | 
