[SOLVED] Local package isn't recognized even with __init_

Local package isn't recognized even with __init__.py

Original question

Current project setup is

project/
├─ ams/
│  ├─ __init__.py
│  ├─ common/
│  │  ├─ dataclasses.py
│  │  ├─ __init__.py
├─ entry_point/
│  ├─ bar_api/
│  │  ├─ swagger/
│  │  │  ├─ main.yaml
│  │  ├─ __init__.py
│  ├─ run.py
│  ├─ __init__.py

with run.py having a line from ams.common.dataclasses import Foo, which gives me an ImportError when I run run.py both from project root via python entry_point/run.py and via python run.py after moving to entry_point.

As you can see, I have __init__.py literally everywhere, and the project seems to work with the current setup for the other developer (I'm just trying to deploy it locally to test stuff).

I've seen suggestions of adding some variation of the path to the project root to PYTHONHOME or PYTHONPATH env variables via the env activation script, but trying this lead me to ModuleNotFoundError: No module named 'encodings' and a traceback that suggests Python is looking in the wrong directory for the stdlib. Googling said error leads to a dicussion on Github that suggests modifying either of those variables is a sign you're doing something wrong and should not be done.

At this point, what do I do?

Update 1

Moving run.py to root and running it from there presented me with an file not found error: FileNotFoundError: [Errno 2] No such file or directory: 'bar_api/swagger/main.yaml' I've added in the updated project structure. I assume this time the working directory should be entry_point, so by now I'm heavily inclined towards adding every single folder in the project directory to PYTHONPATH.

Solution

Adding

_OLD_VIRTUAL_PYTHONPATH="$PYTHONPATH"
export PYTHONPATH="$VIRTUAL_ENV:/path/to/project:$PYTHONPATH"

and the corresponding revert in deactivate()

if ! [ -z "${_OLD_VIRTUAL_PYTHONPATH+_}" ] ; then
    PYTHONPATH="$_OLD_VIRTUAL_PYTHONPATH"
    export PYTHONPATH
    unset _OLD_VIRTUAL_PYTHONPATH
fi

to the venv activation script and running run.py directly from entry_point (in that way specifically, not from project root) did the trick while being the least intrusive option.