organizing your scripts, with plenty of re-use

[Robert Kern]

On 2009-10-05 13:48 PM, Buck wrote:
> On Oct 5, 11:29 am, Robert Kern<robert.k... at gmail.com>  wrote:
>> On 2009-10-05 12:42 PM, Buck wrote:
>>
>>
>>
>>>> With the package layout, you would just do:
>>
>>>>      from parrot.sleeping import sleeping_in_a_bed
>>>>      from parrot.feeding.eating import eat_cracker
>>
>>>> This is really much more straightforward than you are making it out to be.
>>
>>> As in the OP, I need things to "Just Work" without installation
>>> requirements.
>>> The reason for this is that I'm in a large corporate environment
>>> servicing many groups with their own custom environments.
>>
>> The more ad hoc hacks you use rather than the standard approaches, the harder it
>> is going to be for you to support those custom environments.
>
> I too would prefer a standard approach but there doesn't seem to be an
> acceptable one.
>
>> I do believe that you and Stef are exceptions. The vast majority of Python users
>> seem to be able to grasp packages well enough.
>
> You're failing to differentiate between python programmer and a
> system's users. I understand packages well enough, but I need to
> reduce the users' requirements down to simply running a command. I
> don't see a way to do that as of now without a large amount of
> boilerplate code in every script.

I would like to see an example of such boilerplate. I do not understand why 
packages would require more than any other organization scheme.

> I've considered installing the thing to the PYTHONPATH as most people
> suggest, but this has two drawbacks:
>    * Extremely hard to push thru my IT department. Possibly impossible.
>    * Local checkouts of scripts use the main installation, rather than
> the local, possibly revised package code. This necessitates the
> boilerplate that installation to the PYTHONPATH was supposed to avoid.
>    * We can work around the previous point by requiring a user-owned
> dev installation of Python, but this raises the bar to entry past most
> of my co-developers threshold. They are more comfortable with tcsh and
> perl...

Are you sure that you are not referring to site-packages/ when you say "PYTHONPATH"?

PYTHONPATH an environment variable that the user can set. He can add whatever 
directories he wants to that environment variable. The user can make a directory 
for his checkouts:

   $ mkdir ~/LocalToolCheckouts
   $ cd ~/LocalToolCheckouts
   $ cvs ...

Now add that directory to the front of his PYTHONPATH:

   $ export PYTHONPATH=~/LocalToolCheckouts/:$PYTHONPATH

Now everything works fine. Packages in ~/LocalToolCheckouts will get picked up 
before anything else. This is a simple no-installation way to use the normal 
Python package mechanism that works well if you don't actually need to build 
anything.

> I think the issue here is that the current python-package system works
> well enough for the core python devs but leaves normal python
> developers without much options beyond "all scripts in one directory"
> or "tons of boilerplate everywhere".

The "vast majority" I am talking about *are* the normal Python developers.

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