The topic of the vileness of Fink or MacPorts came up in python-dev when
discussing building a Mac installer.  I remembered that a couple /sw and
/opt/local directories are searched unconditionally, making it a bit
more challenging for someone to create a framework build which didn't
rely on one or the other.

The attached makes the addition of /sw/... or /opt/local/... directory
searches conditional on the presence of /sw/bin or /opt/local/bin in
PATH.  I don't have more time to expand upon the concept more, but it
might also be useful to exclude other platform-dependent optional
directories from searching (such as /opt/sfw for Solaris).

I think this is essentially a duplicate of Issue7713.
(Also there doesn't seem to be an "attached".)

Let's try this again.

The patches referenced in issue7713 just unconditionally delete certain
directories from the search path(s).  This patch (now attached) allows
the user to control that.  I presume, for instance, if the MacPorts
folks don't want /usr/X11/... in search paths that they don't have
/usr/X11/bin in PATH when they build Python.  This concept can be
extended to other such directories.  I was mostly concerned about the
Fink and MacPorts directories since they came up in the thread on
python-dev.

Without testing it, I'd guess the patch wouldn't hurt but it also wouldn't affect the OS X installer build as the installer script builds a local copy of Sleepycat db4 (since none is included in OS X) and supplies it as an additional local library/include file which is always found first by the setup.py code, so it never gets to searching the additional paths affected by the patch.  If you are building manually and don't supply a local lib, then the build of the dbm extension will either fail or it will try to use a MacPorts or Fink version if available.

Ned: the patch does have a (positive) effect when building the OSX installer: the build-installer script creates private builds of a number of libraries, but setup.py can detect other libraries (such as libintl) as well and we don't guard against that at the moment.

Skip: I'm +0 on including this functionality, but haven't looked at the patch yet.

To be honest I'd must rather remove /opt/local and /sw entirely from setup.py and add new configure flags to specify the location of a number of libraries (e.g. 'configure --with-sleepycat-db=/opt/local').  Explicit configure flags is what other OSS packages seem to use to specify that you like to use a library that is not in /usr or /usr/local.

Ronald> To be honest I'd must rather remove /opt/local and /sw entirely
    Ronald> from setup.py and add new configure flags to specify the
    Ronald> location of a number of libraries (e.g. 'configure
    Ronald> --with-sleepycat-db=/opt/local').  Explicit configure flags is
    Ronald> what other OSS packages seem to use to specify that you like to
    Ronald> use a library that is not in /usr or /usr/local.

Right, but then you still have the problem with /usr/local (note the package
patches mentioned in the other issue), and you'd have to go through that
dance for every bit of functionality which might be found in an external
library.

Someone else (David Cornapeau?) mentioned he just uses a chroot jail to
build numpy and scipy installers.  That might ultimately be the best way to
do things.

Skip

Ronald, as far as I can see, the patch as it stands only addresses dbm so more work is needed to address all the other cases, the ones that actually matter. Issue7713 describes a more serious, general problem because a number of other builders / distributers have the same problem, and not only on OS X.  Everyone currently needs to maintain their own set of patches on top of every release to modify setup.py's search behavior.  That's where the effort should go, I think.

Skip, I saw David's chroot remark but I'm having a hard time envisioning how one could use that as a practical matter to build an OS X framework without some *serious* changes to the current configure(s), Makefile(s), and installer script.

Sorry, Ronald, of course that's what you were suggesting with the proposed configure --with options.  +1 on that.  I'd just want to ensure that any solution addresses any needs in Issue7713, too.  Something like that should.  There are probably other open issues in a similar vein.