organizing your scripts, with plenty of re-use

Robert Kern robert.kern at
Mon Oct 5 23:19:04 CEST 2009

On 2009-10-05 15:33 PM, Margie wrote:

> I think he is looking for a way for users to be able to use scripts/
> (which imports parrot) without having to change their
> PYTHON path with something like this:
>     $ export PYTHONPATH=~/LocalToolCheckouts/:$PYTHONPATH
> I'm guessing that Buck has users that are running out of a cvs
> repository.  Although many would say those users are now "developers",
> they really are not.

Since he called them "co-developers", I was operating under the assumption that 
they were, in fact, developers.

> They probably don't even know they are running
> from a cvs repository.  They in fact may think of it as their own
> personal installation, and all they know is that they have scripts
> directory and that that scripts directory has some scripts they want
> to run.
> As Buck said, it can often be very difficult to get things properly
> and quickly installed in a large corporate environment, and providing
> the user with a way to check out a cvs repository can be very quick
> and easy.  The problem is that once the user has access to that cvs
> repository, it is difficult to tell them "hey, every time you run from
> it, you need to execute this special command to set up your PYTHONPATH
> environment variable."

No, you tell them: "Add the line

   source ~/LocalToolCheckouts/tool-env.csh

to your ~/.tcshrc and start a new shell."

They each do this once, and it works for all of your scripts with no 
boilerplate. You can add features to this shell script, too, like adding the 
script directory to their $PATH.

Or you can write a simple "installation" script, which doesn't really install 
anything, just adds to their ~/.tcshrc files like so.

Or if this still is beyond your users, put a module into your scripts directory 
that does the prepends ~/LocalToolCheckouts/ to sys.path . The only 
"boilerplate" you need is one line in each script that imports this module.

But this is all stuff you have to do whether you organize your code into 
packages or not. The organization of the code really has no effect on the 
installation problems the OP faces.

Robert Kern

"I have come to believe that the whole world is an enigma, a harmless enigma
  that is made terrible by our own mad attempt to interpret it as though it had
  an underlying truth."
   -- Umberto Eco

More information about the Python-list mailing list