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

[Bob Ippolito]

On Friday, Oct 10, 2003, at 16:34 America/New_York, Jack Jansen wrote:

>
> 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.

There's nothing stopping the author of setup.py from writing an 
application that doesn't work either.. or stopping the author from 
using Makefile instead of setup.py.  I'm not really concerned with 
these people.

> [*] 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.

That's what I was thinking.  I was actually really surprised that you 
were using bdist_dumb and rewriting the sys.prefix out of the paths to 
do user installs.  Whatever works, right? :)

>> 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).

Let's put that into the distutils discussion.  Python packages should 
have a canonical way of having headers, scripts, dynamic libraries, and 
other arbitrary data (like fonts, icons, etc.) associated with them *in 
the same or folder (or a closely related folder with identical 
permissions)* as the package itself.  We could propose something like 
Apple's bundles for this purpose (sans versioning, most likely).

> - We don't have the authorization API right now

That's not a really good excuse, I can fix that this weekend.

>> 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).

That works too, forgot about that.  It's a shame that site-packages 
isn't allowed to just replace standard library stuff (by way of 
sys.path ordering), since there are so many batteries these days that 
don't necessarily update at the same speed as Python and it's quite 
possible for someone to botch packaging of a battery, such as you 
forgetting to have bsddb installed when you packaged Python ;)

-bob