Re: [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

for OS-X get applied by the package maintainers.

Then things will "just work"

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

-bob

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.

Ronald

smime.p7s
Description: S/MIME cryptographic signature

_______________________________________________
Pythonmac-SIG maillist  -  Pythonmac-SIG@python.org
http://mail.python.org/mailman/listinfo/pythonmac-sig