You can use the Site-specific configuration hook.

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

In your case, you should be able to achieve what you want by simply dropping in a .pth file containing the path of the directory to include:

[root@home]$ echo "/usr/local/lib/python2.7/site-packages/" > /opt/python2.7.2/lib/python2.7/site-packages/usrlocal.pth

The site module documentation and Modifying Python's Search Path seem to be what you're looking for.

As far as I understand it, those entries are being added to sys.path by:

• /usr/lib/python2.6/site.py
• /usr/lib/python2.6/dist-packages/site.py
  (Change 2.6 to your version of Python.)

The easiest way to change it is to add a file /usr/local/lib/python2.6/dist-packages/site-packages.pth containing ../site-packages.

Alternatively, maybe you can teach the package to use site.getsitepackages()?

There are two types of site-packages directories, global and per user.

1. Global site-packages ("dist-packages") directories are listed in sys.path when you run:

    python -m site
   

   For a more concise list run getsitepackages from the site module in Python code:

    python -c 'import site; print(site.getsitepackages())'
   

   Caution: In virtual environments getsitepackages is not available with older versions of virtualenv, sys.path from above will list the virtualenv's site-packages directory correctly, though. In Python 3, you may use the sysconfig module instead:

    python3 -c 'import sysconfig; print(sysconfig.get_paths()["purelib"])'
   

2. The per user site-packages directory (PEP 370) is where Python installs your local packages:

    python -m site --user-site
   

   If this points to a non-existing directory check the exit status of Python and see python -m site --help for explanations.

   Hint: Running pip list --user or pip freeze --user gives you a list of all installed per user site-packages.

Practical Tips

• <package>.__path__ lets you identify the location(s) of a specific package: (details)

    $ python -c "import setuptools as _; print(_.__path__)"
    ['/usr/lib/python2.7/dist-packages/setuptools']
  

• <module>.__file__ lets you identify the location of a specific module: (difference)

    $ python3 -c "import os as _; print(_.__file__)"
    /usr/lib/python3.6/os.py
  

• Run pip show <package> to show Debian-style package information:

    $ pip show pytest
    Name: pytest
    Version: 3.8.2
    Summary: pytest: simple powerful testing with Python
    Home-page: https://docs.pytest.org/en/latest/
    Author: Holger Krekel, Bruno Oliveira, Ronny Pfannschmidt, Floris Bruynooghe, Brianna Laugher, Florian Bruhin and others
    Author-email: None
    License: MIT license
    Location: /home/peter/.local/lib/python3.4/site-packages
    Requires: more-itertools, atomicwrites, setuptools, attrs, pathlib2, six, py, pluggy
  

(Please correct errors and omissions as necessary. Thanks.)

First, a question and a comment. I don't use SUSE, so take this with a pinch of salt. Are the packages that install in /usr/lib/python2.6/site-packages official packages? If so, SUSE is broken, so that is not likely. If they are not official packages, you could either ask the packagers to use the standard paths, or, alternatively, you could submit a wishlist bug to SUSE asking them to support this additional path. This will save you and other people additional headaches.

For the moment, you have the following possibilities, in order of decreasing scope:

1. Change the module search path for all users (method 1)

   Change the module search path in the Python installation.

   The default module search path is hardwired into the binary. Add-on paths can be configured at runtime, for example in the site.py file. For example, Debian uses /usr/lib/python2.6/site.py (for the default python 2.6 installation) to do its site-specific configuration. At the top of the file is written

   Append module search paths for third-party packages to `sys.path`.
   
   ****************************************************************
   * This module is automatically imported during initialization. *
   ****************************************************************
   [...]
   
   This will append site-specific paths to the module search path.
   

   The Debian patch debian/patches/site-locations.diff says

   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/{lib,share}/python/dist-packages. /usr/lib/python/site-packages is not used.

   The patch in question is

                   sitedirs.append(os.path.join(prefix,
   "Lib", "site-packages"))
                elif os.sep == '/':
       +            sitedirs.append(os.path.join(prefix,
   "local/lib",
       +                                        "python" + sys.version[:3],
       +                                        "dist-packages"))
                    sitedirs.append(os.path.join(prefix,
   "lib",
                                                "python" + sys.version[:3],
       -                                        "site-packages"))
       -            sitedirs.append(os.path.join(prefix,
   "lib", "site-python"))
       +                                        "dist-packages"))
       +            sitedirs.append(os.path.join(prefix,
   "lib", "dist-python"))
                else:
                    sitedirs.append(prefix)
                    sitedirs.append(os.path.join(prefix,
   "lib", "site-packages"))
   

   So you could modify the site.path in your system package to produce a modified module search path. You probably don't want to this, though. For one thing, you will have to merge this in on every update of your distribution's python package.

2. Change the module search path for all users (method 2)

   Add a file of the form something.pth to a directory that is already in the search path, which contains a path, either relative or absolute. Eg.

   /usr/local/lib/python2.6/dist-packages$ cat foo.pth 
   /home/faheem/dummypythonpath
   

   In another terminal do

   >>> import sys
   >>> sys.path
       [...,'/home/faheem/dummypythonpath',...,]
   

3. Change the module search path for all users (method 3)

   The environment variable PYTHONPATH is normally used to append to the system path at user level. You can put it in a file which will be sourced by all users. Eg. in Debian we have /etc/bash.bashrc, which says at the top

   # System-wide .bashrc file for interactive bash(1) shells.
   
   # To enable the settings / commands in this file for login shells as well,
   # this file has to be sourced in /etc/profile.
   

   So you could add or PYTHONPATH there. You probably want it to be sourced for both login and interactive shells, so you'll want to check on that. Unfortunately, distributions are often flaky about enabling this.

   The paths in PYTHONPATH are added to the default list of search paths in the system (which can be obtained for example by sys.path - see below). Allowing for the possibility that PYTHONPATH is set already, just add desired additional directories to it, eg.

   export PYTHONPATH=$PYTHONPATH:"/home/username/lib/python2.6/dist-packages"
   

   If you source the PYTHONPATH variable, and then check sys.path again, you will
   see the paths have been added. Note that the position in which the paths in
   PYTHONPATH are added to the pre-existing paths does not seem to be prescribed by
   the implementation.

4. Change the module search path per user.

   The usual way is to change PYTHONPATH in the user's bashrc, namely ~/.bashrc. Again, check that it is sourced for both login and interactive shells.

5. Change the module search path on a per script basis. This is done by appending to sys.path, namely

   import sys
   sys.path.append(some_additional_path)
   

   This will only work for the script that is importing this. This is normally used, as far as I know, for casual use, when importing modules in nonstandard locations, like from somewhere in a home directory.

See also Greg Ward on Modifying Python's Search Path. This has a good discussion of the available alternatives.

site-packages is the target directory of manually built Python packages. When you build and install Python packages from source (using distutils, probably by executing python setup.py install), you will find the installed modules in site-packages by default.

There are standard locations:

• Unix (pure)¹: prefix/lib/pythonX.Y/site-packages
• Unix (non-pure): exec-prefix/lib/pythonX.Y/site-packages
• Windows: prefix\Lib\site-packages

¹ Pure means that the module uses only Python code. Non-pure can contain C/C++ code as well.

site-packages is by default part of the Python search path, so modules installed there can be imported easily afterwards.

Useful reading

• Installing Python Modules (for Python 2)
• Installing Python Modules (for Python 3)

1. as suggested in the comments: don't use sudo pip install as you will get conflicts with the system package manager sooner or later. Always install python packages via pip install --user.

2. $HOME/.local/lib/python3.6/site-packages shouldn't be on PATH, it's the directory containing python modules (python source code files), but no executables. You can check the path for user-installed executables with:

   $ python3 -m site --user-base | xargs -I {} echo {}/bin
   

   Most probably it's the $HOME/.local/bin. Add this one to PATH instead of site-packages. In your .profile/.bashrc/.bash_profile (whatever your OS specifies):

   PATH="$HOME/.local/bin:$PATH"
   export PATH
   

   Notice the $PATH instead of PATH in the path appending command. Now restart the terminal (or source the profile file) and check whether the installed executables are available:

   $ which eb
   $ eb --help
   

   etc.

If you're using bash (on a Mac or GNU/Linux distro), add this to your ~/.bashrc

export PYTHONPATH="${PYTHONPATH}:/my/other/path"

You covered how Python 2.7 was installed (which is a manual installation), how are you installing your modules?

If you sudo yum install <python-package>, you are going about this using system level (distribution specific) way of getting packages installed, which means it will only put packages in the system python location, in your case in the site-package directory in python2.6.

If you had used sudo pip install <python-package>, it should possibly work since you completely destroyed the default python installation which yum might have need (refer to Upgrade python without breaking yum).

With virtualenv, you can specify isolated, local locations for which you can install python packages to, isolating them from system level and you can fix a virtualenv to any available versions of python on your system, guaranteeing the right sets of libraries with the right sets of packages with all the correct versions (for python and the packages) specific to the needs of a particular application, which means you don't have to deal with the system/distribution level python path issues as that can be a huge source of headache. For example, on the system level you have a package by your distro that depends on some old versions of sqlalchemy, but in your actual application you need the most recent version, with virtualenv you can mask out the system level package and have the latest version installed locally there.