1

Pay attention to the leftmost value of sys.path, besides the empty string...

from root directory, python -c "import sys; print(sys.path)" gives me:

['', '/home/brian/code/indep/chimai', '/home/brian/code/indep/google_search/src', '/usr/lib/python33.zip', 
'/usr/lib/python3.3', '/usr/lib/python3.3/plat-linux', '/usr/lib/python3.3/lib-dynload', '/usr/lib/python3.3/site-packages']

from my home directory:

['', '/home/brian/home/brian/code/indep/chimai', '/home/brian/code/indep/google_search/src', 
'/usr/lib/python33.zip', '/usr/lib/python3.3', '/usr/lib/python3.3/plat-linux', '/usr/lib/python3.3/lib-dynload', 
'/usr/lib/python3.3/site-packages']

from /boot/grub:

['', '/boot/grub/home/brian/code/indep/chimai', '/home/brian/code/indep/google_search/src', '/usr/lib/python33.zip', 
/usr/lib/python3.3', '/usr/lib/python3.3/plat-linux', '/usr/lib/python3.3/lib-dynload', '/usr/lib/python3.3/site-packages']

This behavior continues no matter what directory I test from. That is, the second and third values of sys.path you see should be loaded from my PYTHONPATH variable, but the first one always gets my current directory appended to the front of it.

Also, python -Sc "import sys; print(sys.path) doesn't do this, for some reason. With that command, I always get:

['', 'home/brian/code/indep/chimai', '/home/brian/code/indep/google_search/src', '/usr/lib/python33.zip', 
'/usr/lib/python3.3/', '/usr/lib/python3.3/plat-linux', '/usr/lib/python3.3/lib-dynload']

This is all very surprising. Is site.py responsible for this some how? Can someone point me in the right direction? I am just trying to import my own module, and am currently unable to for some reason.

Brian Peterson
  • 2,800
  • 6
  • 29
  • 36

1 Answers1

0

From the docstring of site.py:

"""Append module search paths for third-party packages to sys.path.

****************************************************************
* This module is automatically imported during initialization. *
****************************************************************

In earlier versions of Python (up to 1.5a3), scripts or modules that
needed to use site-specific modules would place ``import site''
somewhere near the top of their code.  Because of the automatic
import, this is no longer necessary (but code that does it still
works).

This will append site-specific paths to the module search path.  On
Unix (including Mac OSX), it starts with sys.prefix and
sys.exec_prefix (if different) and appends
lib/python<version>/site-packages as well as lib/site-python.
On other platforms (such as Windows), it tries each of the
prefixes directly, as well as with lib/site-packages appended.  The
resulting directories, if they exist, are appended to sys.path, and
also inspected for path configuration files.

A path configuration file is a file whose name has the form
<package>.pth; its contents are additional directories (one per line)
to be added to sys.path.  Non-existing directories (or
non-directories) are never added to sys.path; no directory is added to
sys.path more than once.  Blank lines and lines beginning with
'#' are skipped. Lines starting with 'import' are executed.

For example, suppose sys.prefix and sys.exec_prefix are set to
/usr/local and there is a directory /usr/local/lib/python2.5/site-packages
with three subdirectories, foo, bar and spam, and two path
configuration files, foo.pth and bar.pth.  Assume foo.pth contains the
following:

  # foo package configuration
  foo
  bar
  bletch

and bar.pth contains:

  # bar package configuration
  bar

Then the following directories are added to sys.path, in this order:

  /usr/local/lib/python2.5/site-packages/bar
  /usr/local/lib/python2.5/site-packages/foo

Note that bletch is omitted because it doesn't exist; bar precedes foo
because bar.pth comes alphabetically before foo.pth; and spam is
omitted because it is not mentioned in either path configuration file.

After these path manipulations, an attempt is made to import a module
named sitecustomize, which can perform arbitrary additional
site-specific customizations.  If this import fails with an
ImportError exception, it is silently ignored.

"""

As far as importing your own modules the following rules apply:

If the module is in your current working directory it can be imported with a simple import mymodule if it is in a subdirectory of the current working directory you can import it as subdir.mymodule if you have a package of modules in a subdir of the current working directory and the package includes a file called __init__.py which declares a list called __all__ = ['modulename', 'another', 'etc'] then you can either from subdir import modulename or import subdir and use subdir.etc.fn(), etc.

If your module is one that you need to use in more than one place but not all over the place the you can put it in a common location and then append/insert that location into sys.path when you need it. If it is something that you only need just about all the time then you can add it to your site-packages by putting it in an appropriate location and adding a .pth file. Lastly, if you think that others will benefit from your package you can use distutils to bundle it up and add it to somewhere like the cheese shop or otherwise distribute it.

Steve Barnes
  • 27,618
  • 6
  • 63
  • 73
  • So... sys.prefix is set to the value of $HOME... or something? I don't get what you (or that doc-string, really) are trying to tell me, but I already checked that, sys.prefix is currently set to '/usr', so I don't think it's involved. – Brian Peterson Jul 25 '13 at 06:11
  • I think I'll try to take your suggestion on importing, particularly on appending a location to sys.path; that's pretty smart. – Brian Peterson Jul 25 '13 at 06:33
  • I have a pattern that I regularly use when testing sub-packages that rely on other packages that the main code would have available but that live in sub-directories of the main code rather than of the package item that I would like to stand alone test. All I do is to have some conditional code before the non-system imports that reads `import sys; sys.path.insert(0, '..');` this allows imports that would work when the module is running as a part of the main program to still work for standalone tests. – Steve Barnes Jul 25 '13 at 06:40