[Python-Dev] Re: Path hacking

Guido van Rossum guido@CNRI.Reston.VA.US
Wed, 15 Sep 1999 14:17:55 -0400


> From: "Gordon McMillan" <gmcm@hypernet.com>

> Jim Ahlstrom wtoe:
> 
> > "Guido van Rossum" wrote:
> > > --> The solution:
> 
> Did the dev-list miss something? The last I see is Barry's post.

Hm.  We had an email glitch.  Apparently this message got lost:

Subject: Re: Path hacking
From: Guido van Rossum <guido@CNRI.Reston.VA.US>
To: python-dev@python.org
Date: Tue, 14 Sep 1999 15:57:51 -0400

I just had a long discussion with Barry and Fred, in response to his
registry proposal.  We quickly decided that a Python registry is
overkill for the given problem.  We also quickly came up with a nice
variant of Mailman's approach which will work well in a variety of
cases.

--> The context:

    You have a large complicated application that contains many modules
    spread over many packages, and which has many "top-level" scripts that
    are invoked by the user (or via CGI, for example).  All the code is
    properly packagized, with sufficiently globally unique package names
    being used all over the place.

--> The problem:

    How to get the root directory of your application (where all your
    packages live) on sys.path.

--> The rules:

    Using $PYTHONPATH is right out.

    You can't install new files in the core Python installation directory
    (nor modify existing ones), so using .pth files is also out.

    You don't want to have to edit each of the top-level scripts of your
    application.

    You want a cross-platform solution, in particular it should be
    amenable to Windows.

--> The assumptions:

    You can use a reasonably intelligent installer.

    All your top-level scripts are installed in a single directory (or
    perhaps in a small number of separate bin directories, e.g. bin and
    cgi-bin).

--> The solution:

    Suppose your application (as a whole, not the individual top-level
    script) is called Spam -- this may well also be the name of your
    top-level package.  Then start each top-level script with the single
    line

	import Spam_path

    before importing anything else.

    Your installer, once it knows the absolute pathname of your
    application's root directory, crafts a file Spam_path.py which
    contains code that inserts the right absolute pathname into sys.path.

    Your installer then installs a copy of this file (or a symbolic link
    to it) *in each bin directory where it installs top-level Python
    scripts*.

    Because the script's directory is first on the default path, the Spam
    scripts will pick up Spam_path without any help from $PYTHONPATH.

--> Notes:

    If you are Spam's developer, you probably want to be able to use its
    top-level scripts without having to install them.  All you need to do
    is create a file Spam_path.py pointing to the top of your development
    tree, and set $PYTHONPATH to point to the directory that contains it.

    (Perhaps you already have $PYTHONPATH pointing to a personal directory
    of Python modules you like to have accessible -- then you can just
    drop Spam_path.py there, or link to it from there.)

    Note that adding a personal directory of Python goodies is about the
    only use of $PYTHONPATH that I approve of -- this way, you can set
    $PYTHONPATH in your .profile and never have to change it.

    I know this doesn't resolve the relative import thread (how's that
    going by the way? :-) but Barry & Fred & I agree that this is the best 
    solution to the problem stated in Barry's message to which I am
    following up here.

--Guido van Rossum (home page: http://www.python.org/~guido/)