On 3/13/2011 7:27 PM, bukzor wrote:
I think this touches on my core problem. It's dead simple (and
natural) to use .py files simultaneously as both scripts and
libraries, as long as they're in a flat organization (all piled into a
single directory). Because of this, I never expected it to be so
difficult do do the same in a tiered organization. In fact the various
systems, syntaxes, and utilities for import seem to be conspiring to
disallow it. Is there a good reason for this?
Let's walk through it, to make it more concrete:
1) we have a bunch of scripts in a directory
2) we organize these scripts into a hierarchy of directories. This
works except for where scripts use code that exists in a different
directory.
3) we move the re-used code causing issues in #2 to a central 'lib'
directory. For this centralized area to be found by our scipts, we
need to do one of the following
a) install the lib to site-packages. This is unfriendly for
development,
I find it very friendly for development. I am testing in the same
environment as users will have. I do intra-package imports with absolute
imports. I normally run from IDLE edit windows, so I just tied running
'python -m pack.sub.mod' from .../Python32 (WinXp, no PATH addition for
Python) and it seems to work fine.
> impossible in a corporate environment where the IT-
> blessed python installation has a read-only site-packages.
My package is intended for free individuals, not straight-jacketed
machines in asylums ;-).
--
Terry Jan Reedy
--
http://mail.python.org/mailman/listinfo/python-list
