So the nature is depending on where you run the doctest or where you put your jupyter notebook, all imports inside the project will break!
If you are writing anything more than a single file, a.k.a a module that has directories and subdirectories, which you will import in another place, you are supposed to put everything into a package format and install it with pip install -e ./
Then, within the module are free to use the absolute imports starting with the module name, or relative ones, and it all works like a charm. The import system is designed around this.
Alternatively, you can modify the PYTHONPATH env variable, or modify sys.path dynamically, to append to paths and import directly.
That's not true, why do you think that? Relative Imports are anoying BS, but by default they do work based on the package-hierachy of the executed file, at least with normal Python. It could be there is something in your setup or handling of imports which changes this behaviour, as changing the import-mechnism is possible in python.
> So the nature is depending on where you run the doctest or where you put your jupyter notebook, all imports inside the project will break!
Maybe in those cases, the executed file is not what you think it is? So your top-level package is not located where your test is. Do you execute the test-file directly (python3 test.py), or do you use some starter-script (py.test test.py)?
Anoying because someone 20years ago wrote this bug and no one is able to see and fix it. People derived many workarounds to deal with this flaw , but the design flaw remain unchanged.
If you want to import local files you have to edit the module path to include the current directory.
physics.core module and
chemistry.core module.
But if I add both into sys.path then import .core from physics directory, guess which core will be imported?