Use
def main():
from .submodule1 import hello
# or from Example1.submodule1 import hello
hello.greeting()
if __name__ == '__main__':
main()
It is not finding hello
because it is not in submodule2
folder. You have to give the interpreter the relative path inside the package, or the absolute path in the package. This only works with the from ...
import syntax form.
Omitting the package name can be useful if you have lots of imports and later want to change your package name.
Edit:
This is from the point of view of the code inside the Example1
package, if you turn it into one. That is, this is the way code inside the package Example1
, in some submodule, can refer code inside other Example1
submodule, with submodules placed in different folders also with their __init__.py
inside. This is insider knowledge, but it is to be used from inside the package Example1
. When you are outside, importing the package Example1
, you can import all the names you want to be seen from the outside (in the importer) in the Example1 __init__.py
file.
So I see two different questions here:
How do I refer code from submodule to submodule, with both being inside the same package (do like I said), and how do I export names inside my package to outsiders importing my package (import the names in the package _init__.py
so you can write things like from MyPackage import Class1, Class2, other_name
or even *
- use an __all__
list to control those names).
Also I don't understand why you call submodules to your submodules and then try to install one of them as an isolated package and use it like that. Aren't they part of your Example1
package? If they were isolated packages they shouldn't refer the others...
Stated like this, this may look confusing, actually packages aren't the simplest concept to explain, but it is not that difficult either.
See a clean example I made here on how to organize classes as a package and use them inside the package (insider knowledge of course). Pay attention to the __init__.py
files content as it is similar to what you want to do to make names available outside your package (no inside knowledge except for the importable names).
2nd Edit:
So I trace some source of confusion between me and OP to this:
everything I said above applies to import packages while OP is thinking in terms of distribution packages. Not surprisingly, even the glossary refers this confusion as a real possibility.
Did you try
from . import hello
in the submodule1
import package __init__.py
, instead of import hello
? That should use the submodule1
namespace.
3rd edit:
Your errors might happen because after setting up imports, running with sucess still depends on how you are running the code (I mean from where you import the whole thing), which is usually the package parent folder. If you try to start code from an inside point it can still fail despite being correct (sorry the incoherence).
Even that can be solved with absolute imports but that requires Example1 to become a package, because you have dependencies between the submodules (actually subpackages).
And that leads me to another point:
An import package can contain nested import packages (subpackages), and also modules. That makes it adequate for any project. That means also there is an outer package that contains everything. That is your project. Make releases of that outer package, your project.
Suppose you say "submodules have to be installed separately". Fine. Assuming they are independent, make them packages (they are packages already). Release them separately as above.
Or,
to me they look related, it looks some "submodules" depend on others.
You also say "submodules underneath can be responded by different developers". That is no excuse. It looks to me as a common code base, put them all in version control (you did, didn't you). Tag the files in release points, or put releases in their own branch. Make it all a single package. Release that package.
Otherwise I think you are setting up for chaos. And you are trying to use release packages to control it. How do you keep a log of what version works with what version of another submodule. And if you put the sources of different submodules together for test, they will conflict (override) previously installed submodules in your system.
Also your package will have a single entry point, either a simple import of it or some main hook to run a main function perhaps, not several possible entry points from each "submodule".
I hope that this helps solving your problem, not exactly your error.