What is the use of the path / usr / share / pyshared in python?

I found that some applications developed using python throw their files along this path, what is the use of this path and what files should I embed in it?

+6
source share
2 answers

This directory includes architecture-independent python modules that can be used by several versions of python. Do not manipulate this directory.

See Python Debian Policy . Chapter 1 - Python Package

+2
source

Take a look at the python policy for Debian .

1.5 Path to the module

By default, Python modules are executed in directories listed in the PYTHONPATH environment variable and in the sys.path Python variable. Since version python2.4 is 2.4.5-3, version python2.5 is 2.5.2-7, version python2.6 is 2.6.2-1 and in all versions of python2.7, sys.path does not include the / usr / lib / pythonXY entry .zip. Directories with private Python modules must not be present in sys.path. public Python modules that are not processed by python-central or python support must be installed in the Python module directory of the system, /usr/lib/pythonX.Y/dist-packages for python2.6 and later, and / usr / lib / pythonX.Y / site-packages for python2.5 and earlier. public Python 3 modules must be installed in / usr / lib / python 3 / dist-packages. Modules controlled by python support are installed in another directory which is added to sys.path using the .pth mechanism .. the pth mechanism is documented in the documentation on the Python module site. A special directory is intended for public Python modules installed by the local administrator, / usr / lib / python 3 / dist-packages for all versions of python3, / usr / local / lib / python2.Y / dist-packages for python2.6 and later, and / usr / local / lib / python 2.Y / site-packages for python2.5 and earlier. For local installation by the administrator of python2.6 and later, a special directory is reserved for Python modules that should be available only for this Python, / usr / local / lib / python 2.Y / site-packages (and / usr / local / lib / python 3 / site-packages for all versions of python3). Unfortunately, for python2.5 and earlier, this directory is also visible to the Python system. Additional information on adding the path to the module search path is available in the official documentation of the site module.

When binary packages send the same source code for multiple Python versions, for example / usr / lib / python 2.6 / dist-packages / foo.py and / usr / lib / python 2.5 / site-packages / foo.py, they should point to a common file. Specific version directories for identical source code are not required for python3 and should not be used for this. The common location for sharing, through Python versions, archive files that would otherwise go to the system public module directory is / USR / share / pyshared. No special place required for python3, use / usr / lib / python 3 / dist-packages

1.6 Hooks for updating deadlines

The python binary package has special interceptors that allow other packages to respond to updates of the installed runtime. This mechanism is required to handle changes to the default Python runtime in some packages and to enable Python packaging assistants. There are three types of hooks supported that come in the form of scripts that call Python script runtime package guardian scripts when they are installed, removed, or updated.

/usr/share/python/runtime.d/*. rtinstall: they are called when the runtime is set or maintained. The first argument is "rtinstall", the second argument is malicious runtime (for example, pythonX.Y), and the third and fourth arguments are old and new versions of this packaged runtime if this runtime is already installed but not supported.

/usr/share/python/runtime.d/*. rtremove: they are called when the runtime is removed or is no longer supported. The first argument is "rtremove" and the second argument is harmful runtime (for example, pythonX.Y).

/usr/share/python/runtime.d/*. rtupdate: they are called when by default. The first argument, either "pre-rtupdate", is called before the default runtime change or "rtupdate" is called when the default runtime change or "post-rtupdate" is called immediately afterwards. The second argument is the old standard runtime (for example pythonX.Y), and the third argument is the new default default runtime (for example pythonX.Z).

0
source

All Articles