On 2009-10-05 13:48 PM, Buck wrote:
On Oct 5, 11:29 am, Robert Kern<robert.k...@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
--
http://mail.python.org/mailman/listinfo/python-list
