organizing your scripts, with plenty of re-use
Robert Kern
robert.kern at gmail.com
Mon Oct 5 15:34:36 EDT 2009
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
More information about the Python-list
mailing list