organizing many python scripts, in a large corporate environment.

[bukzor]

On Mar 12, 12:01 pm, "eryksun ()" <eryk... at gmail.com> wrote:
> bukzor wrote:
> > This only works if you can edit the PYTHONPATH. With thousands of
> > users and dozens of groups each with their own custom environments,
> > this is a herculean effort.
>
> ... I don't think it's recommended to directly run a script that's part of a package namespace. Experts on the subject can feel free to chime in.
>

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, and impossible in a corporate environment where the IT-
blessed python installation has a read-only site-packages.
     b) put the lib's directory on the PYTHONPATH. This is somewhat
unfriendly for development, as the environment will either be
incorrect or unset sometimes. This goes double so for users.
     c) change the cwd to the lib's directory before running the tool.
This is heinous in terms of usability. Have you ever seen a tool that
requires you to 'cd /usr/bin' before running it?
     d) (eryksun's suggestion) create symlinks to a "loader" that
exist in the same directory as the lib. This effectively puts us back
to #1 (flat organization), with the added disadvantage of obfuscating
where the code actually exists.
     e) create custom boilerplate in each script that addresses the
issues in a-d. This seems to be the best practice at the moment...

Please correct me if I'm wrong. I'd like to be.

--Buck

--Buck