[Pythonmac-SIG] MacPorts+"make; make install": Etiquette and Sanitation

[Seth Frey]

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.