I've been using *nix variants long enough (OS X 10.6 right now) to be totally reliant on the command line, but not long enough that I've got my head around managing dependencies.
As a beginner, I started using my system's built in version of python, and if I needed a package, I installed ports, and if it wasn't there, I went through MacPython and tried again, and if I needed something that didn't work on those platforms, I used easy_install, or pip or fink or compiled myself, or messed with my path or changed some flags and when none of that worked I installed a newer or older version of Python (2.4 or 2.5 or 2.6 or 2.7 or 3) and tried everything again. Needless to say, using anything with more than a single dependency has been a nightmare, with lots of unprincipled trial and error, and only precarious peace. Two days ago I removed all Pythons except MacPorts 2.6 and Apple's built-in 2.5. No more MacPython. Then I uninstalled, cleaned and reinstalled every Python 2.6 package. I cleaned up my $PATH and $PYTHONPATH, and the latter just uses /opt. Great. One system. Very nice. I did this all to get Some Random Package working (SRP for short, you can perhaps insert igraph, cairo, matplotlib, num/sci/i/py), but after all that, the SRP still didn't work. After a day of trying everything, I uninstalled SRP and py26-SRP from ports, downloaded the most recent source, compiled and installed both myself. And this particular SRP works now. There was a small celebration, but this approach has a downside. In particular, if I ever have a port that depends on the SRP, than I will have to reinstall the troublesome ports. I expect to have to deal with conflicts when this happens. This is already happening in my currently stalled attempts to get pycairo working again. These downsides became apparent when I continued on to try and get SRP2 (cairo) working. Lots of other libraries depend on it, so I can't just uninstall it. I'm in the middle of this, and looking at another day of hacking away. Right now I've deactivated the SRP2 and py26-SRP2 ports. I didn't favor deactivation to uninstallation because I fully understand the consequences of deactivation, but because MacPorts let me. This is a good example of the unprincipled approach. With SRP2 deactivated, have I accidentally broken its dependents? Are those dependents using the SRP2 I compiled instead of the deactivated one that ports intended them for? Will this lead to problems? Recognizing that these questions as a warning sign, I'm worried that I'm not working towards peace. I figured that before I do more the wrong way, I should just ask the people who know about the right way. There are so many little decisions involved in keeping a sanitary, easy-to-maintain ecosystem of libraries: *I figure that I will inevitably have to go to source every now and then. I need a way to gingerly navigate any potential conflicts with an existing port of the same library. How do I walk the line, getting a port's dependents to only use it, while getting my scripts to only use the self-compiled new version. Is that even what I want? I suspect that the answer to this and all my other questions is at http://guide.macports.org/, but too much of it was over my head. I don't speak that language yet. *When I have different versions of a library to choose from, I can select one during compilation with ./configure, I can prefer one in my .profile, or even keep multiple eggs in different locations and prefer one by extending python's sys.path in each script I write. Which of these is considered kludge and what are the best practices and rules of thumb. I realize that "it depends," a lot, but if any heuristics pop to mind, I'd be very grateful. *Since MacPort's python has trumps, every homemade egg now installs itself in opt (the crazy /opt/.../Python.framework/.../site-packages path). Is that unsanitary since it wasn't from ports? Am I setting myself up for headaches? These little things are exactly the little incremental procedural specs that pile up and eventually make everything go to hell. I'm not so interested in advice for this or that library, but an approach that will serve me well forever as a kludge-prone *NIX user who is tired of getting into trouble. Is there some article about managing libraries that I should have read years ago? Is this suffering simply a part of life? Are there best practices, or does everyone have their own special approach with its own special problems? Sorry this was so long-winded. Thank you for your help. Hopefully I'm not alone here. Best, seth. _______________________________________________ Pythonmac-SIG maillist - Pythonmac-SIG@python.org http://mail.python.org/mailman/listinfo/pythonmac-sig unsubscribe: http://mail.python.org/mailman/options/Pythonmac-SIG