[Pythonmac-SIG] best way to install packages?

[Ronald Oussoren]

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  
>>> will
>>> run on 10.4 also)
>>>
>>> 2.4.1 framework build for 10.4
>> Don'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.
>
> OK. 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 install
>> software 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  
>> users
>> and 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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 2157 bytes
Desc: not available
Url : http://mail.python.org/pipermail/pythonmac-sig/attachments/20060204/82672c73/attachment.bin