Subject: Re: Can we solve the "two Pythons on 10.3" problem? - msg#00318

Previous Message by Date: click to view message preview

Re: Can we solve the "two Pythons on 10.3" problem?

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 smime.p7s Description: S/MIME cryptographic signature _______________________________________________ Pythonmac-SIG maillist - Pythonmac-SIG@xxxxxxxxxx http://mail.python.org/mailman/listinfo/pythonmac-sig

Next Message by Date: click to view message preview

Building on Panther for Jaguar deployment

[I'm changing the subject so this discussion won't pollute the other thread too much] On 27 Nov 2003, at 23:58, Bob Ippolito wrote: 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? Isn't it good enough to just install Jaguar MacPython, set the MACOSX_DEPLOYMENT_TARGET environment variable and use /usr/local/bin/python to run your setup.py scripts? As a sideline, there's a feature request plus patch for enabling cross-compilation (www.python.org/sf/848910) that may or may not be of interest to this. -- Jack Jansen <Jack.Jansen@xxxxxx> http://www.cwi.nl/~jack If I can't dance I don't want to be part of your revolution -- Emma Goldman _______________________________________________ Pythonmac-SIG maillist - Pythonmac-SIG@xxxxxxxxxx http://mail.python.org/mailman/listinfo/pythonmac-sig

Previous Message by Thread: click to view message preview

Re: Building on Panther for Jaguar deployment

On 28 nov 2003, at 14:53, Bob Ippolito wrote: On Nov 28, 2003, at 4:47 AM, Jack Jansen wrote: [I'm changing the subject so this discussion won't pollute the other thread too much] On 27 Nov 2003, at 23:58, Bob Ippolito wrote: 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? Isn't it good enough to just install Jaguar MacPython, set the MACOSX_DEPLOYMENT_TARGET environment variable and use /usr/local/bin/python to run your setup.py scripts? I doubt that, have you tried it? Have you tried it with PyObjC (which has 10.3 specific features)? It will definitly not work with PyObjC, the scripts that generate wrappers for static items (global functions, constants) are pretty stupid and don't recognize the #if guards for new features (e.g. even if you manage to get a compiler that generates 10.2 libraries the compilation will fail because the generated wrappers refer to 10.3 specific features). The core module should be fine, it contains #if guards for 10.3 specific features. Ronald -bob_______________________________________________ Pythonmac-SIG maillist - Pythonmac-SIG@xxxxxxxxxx http://mail.python.org/mailman/listinfo/pythonmac-sig _______________________________________________ Pythonmac-SIG maillist - Pythonmac-SIG@xxxxxxxxxx http://mail.python.org/mailman/listinfo/pythonmac-sig

Next Message by Thread: click to view message preview

Re: Can we solve the "two Pythons on 10.3" problem?

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 28/11/2003, at 9:39 AM, 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. Solution for all problems... Apple rolls out Python updates with their other patches. I assume *somebody* asked, and it isn't going to happen for resource, cultural or political reasons? - -- Stuart Bishop <stuart@xxxxxxxxxxxxxxxx> http://www.stuartbishop.net/ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.3 (Darwin) iD8DBQE/xzFEAfqZj7rGN0oRArhpAJ9qpVWUueR0JxdR1gdX+0f1Wu6WWACeP6xO l8YER/zf7/j2mWDp73464sc= =DTQo -----END PGP SIGNATURE----- _______________________________________________ Pythonmac-SIG maillist - Pythonmac-SIG@xxxxxxxxxx http://mail.python.org/mailman/listinfo/pythonmac-sig