[Pythonmac-SIG] PackMan - in defence of Python code in the database

[Jack Jansen]

On 10-okt-03, at 18:29, Bob Ippolito wrote:

>> 1. binary distributions are specific to the install location of 
>> Python,
>>    they're basically tar files. So, a binary distribution for 
>> Apple-MacPython
>>    is different from a binary distribution for JackJansen-MacPython.
>>    We work around this for per-user installs, but at a cost (such as 
>> C header
>>    files not being installed). So, I needed a new test to see where 
>> sys.prefix
>>    was pointing.
>> 2. In Apple-installed Python sys.prefix/include/python2.3 is 
>> root-owned and
>>    readonly. This makes installers like Numeric fail (which want to 
>> write there).
>>    So I needed a new test for this (with the description being an 
>> explanation
>>    of the unix commands to run to fix this).
>>
>> All of these could have been handled in pimp itself, of course, but 
>> pimp
>> is already out there, as distributed by Apple...
>
> 1.  This is because we're using bdist_dumb, which is just as smart as 
> it sounds.  We'll inevitably be using something else in the future 
> that's a lot smarter.

Definitely (and actually fairly simple[*]), but even then you cannot be 
100% sure that any binary distribution can be re-targeted to a 
different location. There's nothing stopping the author of setup.py to 
store sys.prefix in a datafile somewhere.

[*] Now that Python has its own tar module we could have a 
bdist_slightlylessdumb that creates a tarfile that has magic tokens for 
places like sys.prefix, etc. While a normal tar couldn't extract these 
to the right place a Python script to do so is dead simple.

> 2.   We shouldn't really be putting things in /System, ever.  Anything 
> that does system-wide installation should use the authorization API in 
> order to acquire root access, even if the user has admin gid.

In theory I agree with this. In practice there are a number of problems:
- Not putting anything into /System conflicts with the accepted Python 
usage of packages adding stuff to include/python2.3. Until 
Python/distutils learn about a secondary include directory I think we 
have no options but putting things into /System (or not allowing it, at 
the expensive of disabling Numeric support in many packages).
- We don't have the authorization API right now

> 3.  It's not hard to put a revised pimp inside a revised 
> PackageManager app bundle, or just rename pimp as the consensus seems 
> to be (although, I kinda like it).

Actually, that wouldn't even be needed due to pimp's ability to update 
itself: just add a module pimp_update to site-packages and pimp will 
override itself with the contents of that module (if the version number 
is higher).
--
Jack Jansen, <Jack.Jansen at cwi.nl>, http://www.cwi.nl/~jack
If I can't dance I don't want to be part of your revolution -- Emma 
Goldman