organizing many python scripts, in a large corporate environment.

bukzor workitharder at gmail.com
Mon Mar 14 02:40:38 EDT 2011


On Mar 13, 6:50 pm, Terry Reedy <tjre... at 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



More information about the Python-list mailing list