[Pythonmac-SIG] Can we solve the "two Pythons on 10.3" problem?

[Bob Ippolito]

On Nov 27, 2003, at 5:39 PM, Jack Jansen wrote:

> Folks,
> with Python 2.3.3 drawing near I wonder whether we can solve the 
> problem
> that having two MacPythons on 10.3 (Apple-installed 2.3 in /System
> and user-installed 2.3.3 in /Library) causes all sorts of problems
> with extension modules being used with the wrong Python.
>
> I'd like to take inventory of the problems, and the possible solutions.
> Please fire away, both with problems I've missed and with solutions.
>
> Here are some of the problems I'm aware of:
> Problem 1. PackMan uses the same database for both Pythons.
> Solution 1a. Use a different database URL template for 2.3.3.

This one gets my vote because it's easiest.  I think I'll be spending 
my time with Apple's 2.3.0, none of the 2.3.0 bugs have really bit me 
(other than datetime being horrifyingly slow).

> Solution 1b. Make a unified database. This has the disadvantage that 
> with
> the current pimp the database will become ugly (two versions of every 
> package
> will be listed) but this is solvable with a new pimp version that 
> conditionally
> hides packages. Still, much more work than 1a.

Solution 1c. Make a new version of pimp that integrates with macholib 
and can relocate the mach-o headers of installed bundles (python 
extension modules) appropriately.  macholib is just about ready for 
prime time, I have it integrated with bundlebuilder, but have not done 
extensive testing.  Expect to see something from me Sunday or Monday 
(not PIMP integration, but something cleaned up and tested).

> Problem 2. Users copy extension modules from one Python to the other.
> Solution 2. Document clearly, and in many places, that you should not 
> do
> this.

Solution 2c.  Provide a command line tool or droplet that will use 
macholib to relocate all the .so's in a package and copy them to the 
right place?

> Problem 3. ~/Library/Python/2.3/site-packages is shared between the 
> Pythons. This
> is the one I don't really have a solution for that I like, so fire 
> away.
> Solution 3a. For 2.3.3 we use a different path. Don't like this 
> because it'll
> also reflect on Jaguar users upgrading (who suddenly lose their 
> personally installed
> packages).
> Solution 3b. We recognize that this is really a general problem, and 
> warn
> in Package Manager when you're installing extension modules into the 
> per-user
> directory.

Also /Library/Python/2.3 has this same problem, does it not?

> Problem 4? I haven't tested yet what happens when 2.3.3 installs a
> different Apple Help Book from the standard one. I hope the new one 
> overrides
> the old one, but I'm not sure. If in stead the old one overrides the
> new one we have no way of using the Help Book to give information on 
> the
> issues above.

I should try using the python help book some day.. I've never really 
liked help book, though.

Problem 5.  Being an app developer sucks if you want to support Jaguar, 
but want to run Panther.  Someone needs to really sit down and figure 
out how to "chroot" a Jaguar version of MacPython, and convince 
distutils to use 10.2 as a deployment target and link against all the 
stuff in /Developer/SDKs/.  Does this have to be me, or is someone else 
willing to try their hand at this?

-bob
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 2357 bytes
Desc: not available
Url : http://mail.python.org/pipermail/pythonmac-sig/attachments/20031127/b6275142/smime.bin