[Distutils] A prefix option?

[Jim Fulton]

Phillip J. Eby wrote:
> At 07:31 AM 2/9/2006 -0500, Jim Fulton wrote:
> 
>> I really don't think the virtual python approach is viable, at a minimum
>> because it doesn't work on windows.  It is also unacceptably heavy IMO.
> 
> 
> What do you mean by "heavy"?

It essentially duplicates the python install via symbolic links.

> 
>> I think we need a simple way to handle custom directories that is:
>>
>> - cross platform
>>
>> - doesn't require modifying the Python install
>>
>> - allows chained/multile custom directories, which means the trick
>>   of putting eggs and scripts in the same directory doesn't work,
> 
> 
> PYTHONPATH-based installs allow all of this, as long as you add the 
> setuptools .egg to PYTHONPATH.

Agreed. I think PYTHONPATH-based installations are close to what some of us
need.  I think that having to set the path is a hassle that is possible
to overcome and worth doing.  As I've suggested before, since easy
install generates startup scripts, it should be possible to for it
to generate startup scripts that take care of setting the path.

I think it should be possible to have Python startup scripts invoke
setuptools' site.py to add necessary .pth files to the path.  If I'm
wrong, then another option is for setuptools to generate sh scripts
on 'nix platforms, much as it generates exe's on Windows.  (I presume
that the generates exe files on windows then invoke Python and can
also manipulate the environment.)


> 
>> - is simple. :)
> 
> 
> PYTHONPATH is simple everywhere but Windows, and it's complex there only 
> because you have to right click a bunch of icons to get to the editing 
> facility.

Eek.  I would never consider setting the PYTHONPATH that way on Windows
to satisfy this use case.  The fact that you suggest this suggests that
you missunderstand my use case.  OK, I left something out of my bulleted
list:

- Doesn't require changes to a user's profile or anything else outside
   the working directory tree.

> ISTM that what's missing from your requirements statement is how you 
> would like to activate or deactivate these various custom directories.  
> An alternate Python executable?  Script wrappers?  Commands you run to 
> set what directories are active?

I worry that I'm not setuptools zenfull enough to make the best proposal
yet, but here's what I envision so far.

To create a workspace, you create the directory and put a setup.cfg in it.
You then install easy_install into that directory (typically into that
directory's bin directory).  Then when you run that directory's easy_install
script, eggs are installed into the workspace (e.g. into some sort of library
directory within the workspace).  In addition, wrapper scripts build during
the installation set the path and invoke setuptools' site.py to reflect
settings in setup.cfg.

You might be able to think of a better way to do this.

My goal is to have self contained working directories.  In addition,
I want to have chained self-contained working directories, which is
why the excellent "put scripts and eggs in the same place" solution
doesn't work for me (more below).


> 
>> It appears that this has something to do with your plugin proposal.
> 
> 
> Not that I'm aware of, actually.  The plugin facility is intended for an 
> "application instance" path, distinct from a general/global installation 
> location.

But that's exactly what I'm talking about.  To make this more concrete:

My hope is that Zope 3.3 will be highly eggs based.  People expect to be
able to install Zope without odifying Python.  Basically, a Zope install
is a separate "aplication instance". (Note that to leverage distutils,
Zope 3 windows releases have been installed into windows Python installations.
This installation experience has been unpopular.)  I would want a Zope
install to be largely a collection of eggs.  I would also want a Zope
install to support easy installayion of additional eggs into the Zope install
or into a directory associated with the Zope install (probably the later).

A Zope install provides a simple application for creating Zope "instances".
A Zope instance is what actually runs a Zope application server.  Multiple
Zope instances can share a single Zope software install.  (Of course, multiple
Zope sotware installs can share a single Python install.)  Of course, I want
people to be able to install additional eggs, including eggs with scripts,
into the Zope instance.  I don't want users to have to manually manipulate
paths to be able to use these.

Traditionally, in Zope 2, packages installed into Zope instances have been
plug-in-like in that they could just be dropped into a directory and
magically used.  In Zope 3, we've gone for a more explicit approach,
which I think I prefer.  More on that in the plugin thread, which, sadly,
I probably won't have time to contribute more to until this weekend.

Jim

-- 
Jim Fulton           mailto:jim at zope.com       Python Powered!
CTO                  (540) 361-1714            http://www.python.org
Zope Corporation     http://www.zope.com       http://www.zope.org