non-standard module location (again)

[Shane]

Need to refine a question I asked earlier. If I have a module,

|-- foo
|-------|
|-------|---bar
|-------|-------|
|-------|-------|---__init__.py

then I can say import foo.bar

But suppose I want to import foo.bar.stuff and stuff isn't located on
under `bar' because it's user
supplied code:

|- stuff <- I want this to be logically
under foo.bar
|-------|---__init__.py <- even though it's not under bar in
the computer's file system

Now what: how to arrange to do command: import foo.bar.stuff

 

[88888 Dihedral]

1. Define a new class with an instance of the foo class included so that one can use all foo's properties and add new attributes.

2. Derive a new class from foo that extends its properties with the properties in foo accessible.

 

[Ian Kelly]

Need to refine a question I asked earlier. If I have a module,

|--  foo
|-------|
|-------|---bar
|-------|-------|
|-------|-------|---__init__.py

then I can say import foo.bar

But suppose I want to import foo.bar.stuff and stuff isn't located on
under `bar' because it's user
supplied code:

|- stuff                             <- I want this to be logically
under foo.bar
|-------|---__init__.py           <- even though it's not underbar in
the computer's file system

Now what: how to arrange to do command: import foo.bar.stuff

I've never tried this myself, but I think that pkgutil.extend_path is
what you're looking for.

http://docs.python.org/library/pkgutil.html

Cheers,
Ian

 

[Calvin Spealman]

I am biased, but you could use a plugin loader like straight.plugin at
https://github.com/ironfroggy/straight.plugin

 

[Steven D'Aprano]

Need to refine a question I asked earlier. If I have a module,

|-- foo
|-------|
|-------|---bar
|-------|-------|
|-------|-------|---__init__.py

then I can say import foo.bar

No you can't, not the way you have listed it. As shown, foo is just a
directory, so "import foo" will fail. However, "import bar" may work,
provided foo/bar is in the module search path.

Perhaps you mean you have a package, with a sub-package:

foo/
+-- __init__.py
+-- bar/
.... +-- __init__.py

Now you have TWO modules, foo and foo.bar, and you can "import foo.bar"
successfully.

But suppose I want to import foo.bar.stuff and stuff isn't located on
under `bar' because it's user
supplied code:

|- stuff <- I want this to be logically
under foo.bar
|-------|---__init__.py <- even though it's not under bar in
the computer's file system

This is not clear what you are trying to do. Please explain more clearly
what your module layout is.

foo/
+-- __init__.py
+-- stuff.py
+-- bar/
.... +-- __init__.py


Or:

stuff.py
foo/
+-- __init__.py
+-- bar/
.... +-- __init__.py


But since stuff is supposed to be a plugin, the most obvious, sensible
way to lay out the modules would be:

foo/
+-- __init__.py
+-- plugins/
.... +-- __init__.py
.... +-- stuff.py
+-- bar/
.... +-- __init__.py


and then "import foo.plugins.stuff". Clear, simple and obvious.

Now what: how to arrange to do command: import foo.bar.stuff

Why do you want to call it foo.bar.stuff when it isn't actually
foo.bar.stuff? Anyone trying to debug this will hate you, when they try
to find a module foo/bar/stuff.py and can't find it because it doesn't
exist.

If you must play games with module locations, put this inside the
foo/bar/__init__.py module:

import foo.plugins.stuff as stuff

and now you can say "import foo.bar.stuff". But why bother?

Of course, plugin discovery is still a problem, but that's still a
problem no matter what you do. Best to use a well-tested plugin library
instead of trying to invent your own.