[Pythonmac-SIG] best way to install packages?

[Ronald Oussoren]

On 4-feb-2006, at 1:54, Bob Ippolito wrote:
>
>>> 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.
>
> We could do what darwinports does and twiddle their .profile on  
> install to include the framework build dir.  It's nasty, but  
> practicality may beat purity in this case.

Just make sure it is optional, I thoroughly dislike installers that  
modify my profile. I use the same profile on several machines  
(including some that are not running osx).

>
> I don't think Finder-visibility means a damn thing for usability of  
> UNIX applications.  You can't double-click them and have anything  
> useful happen, and seeing them in Finder doesn't put them on your  
> PATH.  It seems futile to install the scripts to yet another non- 
> standard place especially when there are cons to this particular  
> location.

It might help in the discoverability department. But I shouldn't  
comment here, I'm in the "large screens are nice because it allows me  
to open more command-line windows" camp.

>
>>> 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?
>
> There will only be one supported build.  That build will probably  
> support 10.3.9 and later (since that's all gcc4 can do).  Earlier  
> versions of OS X will be ignored.  I definitely don't have the  
> patience/time/resources/hardware to come up with something that  
> runs gcc-3.3 and gcc4 via distutils to build ultra-compatible  
> extensions.  It's not easy.  They take different flags, are  
> compatible with different code, etc
>
> As Ronald said, such a build would have different bugs on i386 and  
> ppc, where the current gcc4 only approach is going to have the same  
> set of bugs unless it's an endian thing.  Dropping support for <  
> 10.3.9 (from the official binaries) is probably inevitable, because  
> supporting new i386 machines is more important than supporting  
> aging PPC machines to the people doing this work, and this is the  
> best compromise.

I have (ugly) patches that make it possible to run on 10.3.9 using  
weak linking. My current universal build uses gcc 3.3 to build  
binaries and uses lipo to merge the i386 and ppc builds.  I'm going  
to port my patches to Bob's tree because that's a much nicer way to  
build and I cannot test on anything before 10.3.9 anyway.

>
> We'll probably need some more tweaks to setuptools to allow it to  
> relax the platform version requirement (e.g. 10.3 users should  
> probably be allowed to try 10.4 eggs and vice versa if exact  
> matches aren't available).

10.4 users should be allowed to use 10.3 eggs, but not the other way  
around. If you (the packager) have binaries that work on 10.3 you  
should provide the right flags to setuptools and create 10.3 eggs.   
Just using 10.4 eggs when available might cause hard crashes, which  
wouldn't help the setuptools cause :-)

>
>> 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"
>
> Assuming the user has developer tools installed, it's not a big  
> deal.  But yes, pushing patches upstream is generally more  
> important than providing binary packages.
>
> -bob
>

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/90f9089e/attachment-0001.bin