organizing your scripts, with plenty of re-use
Rami Chowdhury
rami.chowdhury at gmail.com
Mon Oct 5 17:15:15 EDT 2009
On Mon, 05 Oct 2009 13:46:09 -0700, Buck <workitharder at gmail.com> wrote:
> 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.
>
Perhaps I've simply not followed this thread closely enough but could you
let us know a little bit more about how you intend / expect the scripts to
be used?
If there's a standard directory you expect them to be dropped into by your
users (e.g. $HOME/scripts) then surely you could do something like:
import mypathmunge
at the top of every script, and then have a mypathmunge.py in
site-packages that goes:
# mypathmunge.py
import sys, os
sys.path.insert(0, os.path.join(os.getenv('HOME'), 'scripts'))
?
>
> 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
--
Rami Chowdhury
"Never attribute to malice that which can be attributed to stupidity" --
Hanlon's Razor
408-597-7068 (US) / 07875-841-046 (UK) / 0189-245544 (BD)
More information about the Python-list
mailing list