On 4-feb-2006, at 1:21, Christopher Barker wrote:
Ronald Oussoren wrote:Even more important that versioning is that eggs give you an easy way to uninstall software (although I'm not quite sure about scripts).It really does look like eggs are the way of the future.Bob's "official unofficial" 2.4.1 framework build for 10.3 (this willDon't. There should be only one binary installation of Python 2.4.x for every x and than one should work on 10.3 and 10.4.run on 10.4 also) 2.4.1 framework build for 10.4OK. However, if I understand it, if I am running 10.4, I can run a python and extensions that were built on and for 10.3. However, if I build an extension on 10.4, it may well not work on 10.3. What that means is that anyone building extensions on 10.4 can't contribute to the repository of packages for 10.3.
Most packages should work just fine when build on 10.4, it is important to test this especially for packages that use autoconf.
However, you also can't run extensions built for a 10.3 python on a 10.4 python, which is why this is such a headache! For that matter, can I build extensions to a python built for 10.3 on 10.4 at all without trickery?
That's only a problem for Apple's build of python, they changed the location of site-packages in 10.4. A clean build of python2.4 will alway have site-packages somewhere inside the framework.
I, and all my colleagues, are switching to 10.4 now (I just upgraded to day). I was just thinking I'd go 10.4 across the board, but now I think I may want to stick with a python built for 10.3, if for no other reason that to get wxPython working as easily as possible.> This makes life a lot easier for casual users.Good point. The "standard" approach is for casual users, those doing things like trying to build a universal binary python can do whatever they want!
There should be a good univeral binary build of Python 2.4 soon, Bob has already published a patched python tree that's almost there and I have another set of patches that seem to fix most of the remaining gaps.
I'd prefer /Library/Python/2.x/bin as the directory where scripts get placed because that directory is easily visible in the Finder and allows you to installsoftware for both python2.3 and python2.4.So we need to tell people to add that to their PATH.
Or write a simple (GUI) script to do that for them. Adding to a .bash_profile or .cshrc isn't very hard (for .bash_profile you can just append 'PATH="/Library/Frameworks/Python.framework/Versions/ Current/bin:${PATH}"' to the end of the file, for .cshrc it is something simular) and anyone that has made extensive changes to their profile should be smart enough to do it themselves.
The bin directory inside the framework is a bit to hidden for most usersand hard to get to using the Finder.Maybe we could put a link from /Library/Python/2.x/bin to the bin directory in the Framework. That way, you wouldn't need to change the standard script dir.
That's what I have on my system. The major problem with my setup is that Apple might decide to upgrade to python 2.4 in OSX 10.5 and replace /Library/Python/2.5 with their stuff.
I'll defer to any standard once it is here :-). Feel free to write a proposal about a standard, including what needs to be done to get there ;-)OK, I'll get working on that, once I'm clear about all this 10.3 vs. 10.4 stuff.By the way, is there any advantage of the 10.4 build?
As it is now a 10.4 build supports os.statvfs, os.fstatvfs and os.lchown while the 10.3 build doesn't. The 10.4 build also uses a better API to implement time.time and part of the socket module. I haven't looked at differences in the Carbon namespace yet.
One other thought: having all these different pythons and what not to support is a pain, but really, once you have the setup.py hacked so that it works right, it's no big deal to build a new package. What that means is that the real goal is to make sure that the patches required to build for OS-X get applied by the package maintainers.Then things will "just work"
That's the idea, local patches should be the last resort (e.g. a patch is really needed but the upstream maintainer doesn't want to apply it).
Ronald
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ Pythonmac-SIG maillist - Pythonmac-SIG@python.org http://mail.python.org/mailman/listinfo/pythonmac-sig
