Importing module from another subdirectory

dieter dieter at handshake.de
Tue Apr 23 02:42:00 EDT 2019


Rich Shepard <rshepard at appl-ecosys.com> writes:
> On Thu, 18 Apr 2019, dieter wrote:
> ...
>> 2. extend "sys.path" in your scripts to contain the "bustrac" folder
>> (before you try to import infrastructure modules/packages)
>
> I read the docs for sys and site and have insufficient experience with them
> to know how best to apply them for my needs.
>
> My research suggests that rather than appending a project directory tree to
> sys.path (which would make it visible to all python invocations) I'd be
> better off using site within each project's root directory so modules in
> project-specific subdirectories are available to that project. I would like
> advice on how to do this.

I use "virtualenv" (for "VIRTUAL ENVironmet") to separate
projects. A "virtual environment" behaves (mostly) like a separate
Python installation (while it shares part of a base Python
installation). I ("pip") install there anything needed for the project.
When working with a project, I "activate" the corresponding
"virtual environment" and this gives me a Python tailored for
this project.

Of course, a "project" can be anything - including a "meta project"
just consisting in a selection of other projects.


> ... that rather than appending a project directory tree to
> sys.path (which would make it visible to all python invocations) I'd be
> better off ...

Do not confuse the envvar "PYTHONPATH" with "sys.path".
While "PYTHONPATH" participates in the initialization of "sys.path",
they are quite different: "PYTHONPATH" affects all Python invocations;
"sys.path" is a "runtime thing" - modifications thereof become
effective immediately but only in the running process (not outside).

What I suggested for you would look like:

bustrac/
  ...
  scripts/
    bustrac_setup.py
    script1.py
    ...

Where each "script.py" would contain "import bustrac_setup" (near
its start) and "bustrac_setup" would extend "sys.path" to
make the "bustrac" infrastructure available.


If you are ready to use "virtual environment"s
and ready to learn about advanved Python packaging facilities,
then read the setuptools documentation
(--> "https://setuptools.readthedocs.io/en/latest/").

It has a different approach to your problem and views
scripts as (just) tiny wrappers for infrastructure functions.
Problems to access the infrastructure from scripts are eliminated
(as there is (essentially) only infrastructure).
When "setuptools" "install"s a package into a Python installation
(including a virtual environment), then it creates the
script wrappers in the installation's "bin" folder - ready
for use (once the installation is "activated").
Read "https://setuptools.readthedocs.io/en/latest/setuptools.html#id12"
for details.


Note: a "virtual environment" is required only to separate
projects (and maybe to get a "local" Python installation under your
own control - without help from a system administrator).
"setuptools" works with any Python installation - whether "real"
or "virtual".




More information about the Python-list mailing list