organizing your scripts, with plenty of re-use

[Buck]

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... at 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