[Pythonmac-SIG] best way to install packages?

[Bob Ippolito]

On Feb 3, 2006, at 4:21 PM, 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. 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?

You're really confused here.

> 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.

That's totally backwards...

Chances are, for any given package, it will work best on the newest  
version of Python and OS X, because that's what the core developers  
almost definitely use in their regular workflow.  The exception of  
course is going to be during and shortly after an OS beta, where  
there haven't been enough eyes on things in order to shake out all  
the bugs.

>> 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.

The problem with that is that the /Library/Python/2.x/bin is likely  
to clash with whatever Apple has installed, since they also use those  
locations.  For various reasons, anything we do needs to stay the  
hell out of their way because the vendor distribution is undesirable  
for anyone building redistributable software (or anyone that needs a  
recent build of Python for that matter).

>> 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.

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.

>> 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.

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).

> 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