Thanks. I think we're getting closer to the core of this. To restate my problem more simply:
My core goal is to have my scripts in some sort of organization better than a single directory, and still have plenty of re-use between them. The only way I can see to implement this is to have 10+ lines of unintelligible hard-coded boilerplate in every runnable script. That doesn't seem reasonable or pythonic. On Oct 5, 12:34 pm, Robert Kern <robert.k...@gmail.com> wrote: > I would like to see an example of such boilerplate. I do not understand why > packages would require more than any other organization scheme. This example is from the 2007 post I referenced in my OP. I'm pretty sure he meant 'dirname' rather than 'basename', and even then it doesn't quite work. http://mail.python.org/pipermail/python-3000/2007-April/006814.html import os,sys sys.path.insert(1, os.path.basename(os.path.basename(__file__))) This is from a co-worker trying to address this topic: import os, sys binpath = binpath or os.path.dirname(os.path.realpath(sys.argv[0])) libpath = os.path.join(binpath, 'lib') verinfo = sys.version_info pythonver = 'python%d.%d' % (verinfo[0], verinfo[1]) sys.path.append(os.path.join(libpath, pythonver, 'site-packages')) sys.path.append(libpath) This is my personal code: from sys import path from os.path import abspath, islink, realpath, dirname, normpath, join f = __file__ #continue working even if the script is symlinked and then compiled if f.endswith(".pyc"): f = f[:-1] if islink(f): f = realpath(f) here = abspath(dirname(f)) libpath = join(here, "..", "lib") libpath = normpath(libpath) path.insert(1, libpath) > $ export PYTHONPATH=~/LocalToolCheckouts/:$PYTHONPATH > This is a simple no-installation way to use the normal > Python package mechanism that works well if you don't actually need to build > anything. This seems simple to you, but my users are electrical engineers and know just enough UNIX commands to get by. Most are afraid of Python. Half of them will assume the script is borked when they see a "ImportError: No module named foo". Another 20% will then read the README and set their environment wrong (setenv PYTHONPATH foo). The rest will get it to work after half an hour but never use it again because it was too complicated. I could fix the error message to tell them exactly what to do, but at that point I might as well re-write the above boilerplate code. I'm overstating my case here for emphasis, but it's essentially true. --Buck -- http://mail.python.org/mailman/listinfo/python-list
