[Pythonmac-SIG] PackMan - in defence of Python code in the
Jack.Jansen at cwi.nl
Fri Oct 10 16:34:38 EDT 2003
On 10-okt-03, at 18:29, Bob Ippolito wrote:
>> 1. binary distributions are specific to the install location of
>> they're basically tar files. So, a binary distribution for
>> 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
>> 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
>> of the unix commands to run to fix this).
>> All of these could have been handled in pimp itself, of course, but
>> 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
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
More information about the Pythonmac-SIG