On Feb 6, 2005, at 5:55 AM, Michael Twomey wrote:
On Sat, 5 Feb 2005 13:46:49 -0500, Bob Ippolito <[EMAIL PROTECTED]> wrote:Darwinports gives me the control I need with its flavors (essentially letting you build the package with custom flags, such as with or without X11 support for Vim). I can build several of these and activate/deactivate them whenever I want.
As a rule I dislike flavours (though fink does give you ssl vs non-ssl, and x11 vs non x11 packages), the combinational explosion of options you get means it gets very hard to debug issues with one machine vs another (this probably is another hint of my bias, my arguments stem from maintaining multiple machines, for my laptop this is all really moot :) ).
So then pretend you're using fink and install the same flavor (probably the flavor that depends on a third of the open source software ever written) on every machine.
If I don't want the entire world to be downloaded and installed when installing a simple utility or library.
This isn't really the fault of the system, more of the packager. Fink can handle useful deps just fine, it's a question of whether the packager uses them properly. It's pretty much the same on all systems, AFAIK. As a point of reference, building the suse python package is painful as it draws in a huge amount of deps so it can build all the variant packages.
More linux pain :)
Besides, I thought the reason most people use a packaging system is to pull in a given app's required world of libs rather than download and compile each one?
Yes, but the "world of required libs" is usually mostly satisfied by what is already on the system, though Fink doesn't care because it would rather download and install its own version of everything.
Fink really gets in the way of my efforts to develop redistributable software in that it's dependency resolution is very naive and effectively installs its own OS (minus kernel and a very very small subset of the libraries that OS X ships with). I don't want to distribute an OS with my applications, just the one or two libraries that are actually needed beyond what is included with the OS. I am fine with letting Apple upgrade zlib at their own schedule. I have no need to distribute applications with the absolute latest version of zlib, OpenSSL (and everything else) because I trust Apple (way more so than Fink) to upgrade the OS's version of zlib if there is an actual problem.
I wouldn't use fink to distribute apps, or for that matter any of the packaging systems. In the case of OS X I would link against Apple's libraries, and bundle others I needed. By bundle others, I mean I would build them myself, ensuring they linked against Apple's stuff.
As far as I know, none of the packaging systems touch Apple's libraries (any that went near /usr would be bad news, I'm looking in the direction of the initial release of portage here), they just link against their own versions. With ABI being what it is these days this is a prudent choice. Entire systems like openpkg make this their entire point, they statically link against their own libs so you are isolated from the core OS, a critical point when deploying against multiple OSs.
Darwinports will use Apple's libraries whenever suitable.
Darwinports does have its fair share of disadvantages too, but it's certainly a heck of a lot less annoying for what I do.
Personal preference here, I think it's just a question of which system you like, and which system rubbed you the wrong way when you tried it (for me it was darwinports).
I've been burned by apt on multiple platforms, so :)
All that said, I don't trust either darwinports or fink do manage
Python software. I will use darwinports to build the dependencies for
some things, and build the Python packages myself. As far as Mac
specific patches to Python software goes, I was the originator of them
in many cases... so these "conveniences" don't really apply to me
because I am building and hacking on these things myself anyway (and in
these cases, both fink and darwinports would get in my way, which is
another reason I don't use them for Python software).
I completely agree here. I've adopted a multi-prong approach which works well for me:
1. Use Apple's python (and your sweet pyobjc) for mac apps 2. Use a packaging system (fink, darwinports, whatever) for an X11 or non-gui python. This is what I use from command line. Generally I need more deps for some of this stuff, so a packaging system helps a lot here. 3. 'python setup.py install --prefix=$HOME/unix' and add $HOME/unix/lib/python2.3 to my PYTHONPATH for other stuff which isn't packaged by anyone, generally pure python stuff.
Since you use two different Pythons, how on earth can you use PYTHONPATH? I use pth files sitting in directories that are picked up by a particular Python.
This way I keep the mucking about with my system as root to a minimum, and get reasonable value from pre-packaged stuff.
Packaging systems should be the job of the OS vendor in this day an age. To be honest, I find it shocking that Apple's packaging system doesn't have a package remove, it would make it far more viable. Even better if they adopted a real packaging system like apt ;)
Well, even if apt didn't suck, its license does. Apple stays away from GPL software. I'm pretty sure that there is exactly zero GPL code in Mac OS X (not Server) until you install Developer Tools.
-bob
_______________________________________________ Pythonmac-SIG maillist - Pythonmac-SIG@python.org http://mail.python.org/mailman/listinfo/pythonmac-sig
