On Mar 13, 6:50 pm, Terry Reedy <tjre...@udel.edu> wrote: > 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
virtualenv would let me install into site-packages without needing to muck with IT. Perhaps I should look closer at that.. --Buck -- http://mail.python.org/mailman/listinfo/python-list
