There are currently 73 files with hard-coded references to /usr/local,

To see what I'm talking about, unpack a source Python tarball, and check it out like so:

# cd Python-2.7.3
# grep -Rl '\/usr\/local' ./* | wc -l
73

To read more detail,
# grep -R '\/usr\/local' ./*


Some of these hardcoded /usr/local lines are innocuous or merely misleading,

./README:        1) CONFIG_SHELL=/usr/local/bin/bash CC=cc RANLIB=: \
- or -
./Demo/tkinter/guido/ManPage.py:    MANDIR = '/usr/local/man/mann'

Yet, some of these create unexpected installation behavior when configuring using the --prefix flag to specify an alternative install location, 

./setup.py:        # Ensure that /usr/local is always used
- or-
./setup.py:            db_inc_paths.append('/usr/local/BerkeleyDB.4.%d/include' % x)

(Are items installed outside of your --prefix?  Which ones?  What about dependencies compiled outside of /usr/local?)


###################
A terrible solution

It seems most UNIX package managers elect some form of finding and replace all occurances,  for example,

# dirty deeds, done dirt cheap
for i in `grep -Rl '\/usr\/local' ./*` ; do
   safe sed -i 's#\/usr\/local#\/usr\/mypath#g' "$i"
done

./configure --prefix="/usr/mypath"
...continue the make dance...


#################
A better solution

Prioritize some re-factoring work Python 2.7.3 installation, just enough to get sysadmins like myself by until Python3000 is commonplace...

I'd be happy to help, but as a community outsider, I'm not sure how to make the cleanup work stick.

Thanks for your suggestion.  However, the issue you've created is too wide in scope to be actionable.  As you note, just because the string "/usr/local" appears in a file within the Python source distribution does not indicate a problem.  Many of the cites are in documentation or examples where it is noted or understood that the correct path will need to be supplied or is supplied when the file is actually built and installed.

The one real related issue I am aware of is that the main setup.py, which is used to build the standard library components, does have some hardwired sets of paths, usually including /usr/local, to find necessary third-party libraries and setup.py does not always provide a consistent way to augment those paths.  This is also an issue for cross-compiling Python for other environments.  There are various issues open regarding this, for example, Issue5575 "Add env vars for controlling building sqlite, hashlib and ssl".  I would suggest contributing to those issues by creating or reviewing and testing existing patches.  Also note that Python 2.7.x is open for bug fixes; new features are generally only accepted for the next major release, currently expected to be Python 3.4.  Unless there are more specific items that are not already covered in another issue, I am inclined to close this one.

Hi Ned,

Thanks.  Your logic is rational here, I'll close it, and open another if I can carve out time to attack this with an appropriate patch for setup.py - to attempt resolution of the 3rd party library build issues.

However, off the top of your head if you know of any more related tickets, (like Issue5575), I'd love to know- I'll cull through to try to find as many related bug reports as possible to get a feel for what people have tried.

Best,
.ike