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
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4