Logo Questions Linux Laravel Mysql Ubuntu Git Menu
 

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

Tags:

python

linux

path

I found that some applications developed with python drop their files in this path, what is the use of this path, and what files should I put in it ?

like image 914
Donie Avatar asked Dec 07 '13 08:12

Donie


2 Answers

That directory includes architecture-independent python modules that can be shared by multiple python version. Do not manipulate that directory.

See Debian Python Policy Chapter 1 - Python Packaging

like image 104
falsetru Avatar answered Oct 15 '22 05:10

falsetru


Take a look at the Debian python policy.

1.5 Module Path

By default, Python modules are searched in the directories listed in the PYTHONPATH environment variable and in the sys.path Python variable. Since python2.4 version 2.4.5-3, python2.5 version 2.5.2-7, python2.6 version 2.6.2-1, and in all python2.7 versions, sys.path does not include a /usr/lib/pythonXY.zip entry anymore. Directories with private Python modules must be absent from the sys.path. Public Python modules not handled by python-central or python-support must be installed in the system Python modules directory, /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/python3/dist-packages. Modules managed by python-support are installed in another directory which is added to the sys.path using the .pth mechanism. The .pth mechanism is documented in the Python documentation of the site module. A special directory is dedicated to public Python modules installed by the local administrator, /usr/lib/python3/dist-packages for all python3 versions, /usr/local/lib/python2.Y/dist-packages for python2.6 and later, and /usr/local/lib/python2.Y/site-packages for python2.5 and earlier. For a local installation by the administrator of python2.6 and later, a special directory is reserved to Python modules which should only be available to this Python, /usr/local/lib/python2.Y/site-packages (and /usr/local/lib/python3/site-packages for all python3 versions). Unfortunately, for python2.5 and earlier this directory is also visible to the system Python. Additional information on appending site-specific paths to the module search path is available in the official documentation of the site module.

When binary packages ship identical source code for multiple Python versions, for instance /usr/lib/python2.6/dist-packages/foo.py and /usr/lib/python2.5/site-packages/foo.py, these should point to a common file. Version specific directories for identical source code are not required for python3 and must not be used for this. A common location to share, across Python versions, arch-independent files which would otherwise go to the directory of system public modules is /usr/share/pyshared. For python3, a special location is not required, use /usr/lib/python3/dist-packages

1.6 Hooks for updates to installed runtimes

The python binary package has special hooks to allow other packages to act upon updates to the installed runtimes. This mechanism is required to handle changes of the default Python runtime in some packages and to enable the Python packaging helpers. There are three supported hook types which come in the form of scripts which are invoked from the maintainer scripts of the Python runtime packages when specific installations, removals, or upgrades occur.

/usr/share/python/runtime.d/*.rtinstall: these are called when a runtime is installed or becomes supported. The first argument is "rtinstall", the second argument is the affected runtime (for example pythonX.Y) and the third and fourth argument are the old and new version of this packaged runtime if this runtime was already installed but unsupported.

/usr/share/python/runtime.d/*.rtremove: these are called when a runtime is removed or stops being supported. The first argument is "rtremove", and the second argument is the affected runtime (for example pythonX.Y).

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

like image 28
Steve Barnes Avatar answered Oct 15 '22 04:10

Steve Barnes