[Distutils] API for finding plugins

[Ian Bicking]

Ian Bicking wrote:
> Hmm... and reading over this, I realize that a "plugin directory" is not 
> that different from the virtual python setups, and I think that kind of 
> setup is really the only good way to deploy web applications.  "Working 
> set" -- which is already an idea in setuptools -- is probably the 
> concept that encompasses both uses.  As a developer, I'd like it to be 
> easier and safer to change my working set -- right now I have hacks in 
> sitecustomize and distutils to make that easy.  This switching of 
> working sets is basically what Jim wants in a Zope Instance as well.

One of the open questions I have here, is how the working set is 
determined.  Here's some current practices:

* Scripts include all the information about their working set.  Jim 
brought this up recently, where in addition to the version a script will 
also contain the PYTHONPATH in some form.  In this, you explicitly run 
some particular script, implicitly activating a working set.

* The virtual Python installations basically work like this too. 
"Administrator Install" basically keys it of $HOME, which is great for 
per-user installations but doesn't get any more fine grained.  "Virtual" 
Python uses the Python executable itself, and then all scripts will give 
an absolute path to the executable they use, so this same script-based 
dispatch continues to work with other commands.  "Traditional" 
PYTHONPATH seems a little annoying, but maybe is kind of the right 
direction.

* At work we're using an environmental variable ("ACTIVE_SITE") which 
changes sys.path (in sitecustomize) and the distutils installation 
options.  This is like basing it on $HOME, but a bit more flexible 
(since $HOME has a lot of meanings).  Another option would be some other 
environmental variable with a $HOME fallback.  But this requires some 
distutils monkeypatching to make work.

Are there other ways we can identify the user's intended working set?  I 
don't think environmental variables are easy to work with on Windows, 
and it's a little opaque from a GUI user's perspective.  $HOME isn't 
granular enough.  Multiple scripts can work, but I've found it 
challenging to manage when the binaries in $PATH work, but potentially 
with bad side-effects (the discipline of keeping working sets separated 
isn't enforced, or even suggested by making it easier to do the right 
thing).  Multiple scripts seems the most workable and transparent from 
the point of view of a GUI user, and not particularly bad from the 
perspective of a Posix command-line user either.

[The more I think about it, the more I think site-packages in its 
entirety is pointless, distracting, and dangerous.  But I don't think a 
PEP proposing its removal would be well received at this time ;) ]

-- 
Ian Bicking  /  ianb at colorstudy.com  /  http://blog.ianbicking.org