TL;DR: You can't do relative imports from the file you execute since __main__ module is not a part of a package.

Absolute imports - import something available on sys.path

Relative imports - import something relative to the current module, must be a part of a package

If you're running both variants in exactly the same way, one of them should work. Here is an example that should help you understand what's going on. Let's add another main.py file with the overall directory structure like this:

.
./main.py
./ryan/__init__.py
./ryan/config.py
./ryan/test.py

And let's update test.py to see what's going on:

# config.py
debug = True

# test.py
print(__name__)

try:
    # Trying to find module in the parent package
    from . import config
    print(config.debug)
    del config
except ImportError:
    print('Relative import failed')

try:
    # Trying to find module on sys.path
    import config
    print(config.debug)
except ModuleNotFoundError:
    print('Absolute import failed')

# main.py
import ryan.test

Let's run test.py first:

$ python ryan/test.py
__main__
Relative import failed
True

Here "test" is the __main__ module and doesn't know anything about belonging to a package. However import config should work, since the ryan folder will be added to sys.path.

Let's run main.py instead:

$ python main.py
ryan.test
True
Absolute import failed

And here test is inside of the "ryan" package and can perform relative imports. import config fails since implicit relative imports are not allowed in Python 3.

Hope this helped.

P.S.: If you're sticking with Python 3 there is no more need for __init__.py files.

Your problem might stem from the fact that the directories which you call modules are in fact, in Python's eyes so to speak, nothing but mere directories. In order to get them to be perceived by the interpreter as modules you will have to include a __init__.py file within each directory which hosts Python code.

Though, starting with Python version 3.3 and onwards the need for explicitly defining modules as such has faded, though in some cases sticking to the old way of doing things might prove to be correct and reduce certain errors from popping up; here is an argument as to why you might still have to include an __init__.py file:

Is __init__.py not required for packages in Python 3.3+

If this doesn't solve the issue, i.e. if the error still persists then, the issue might be with your new addition to the Python path, i.e. the app directory.

Based on your comments to orip's answer, I guess this is what happened:

1. You edited __init__.py on Windows.
2. The Windows editor added something nonprinting, perhaps a carriage-return (end-of-line in Windows is CR/LF; in Unix it is LF only), or perhaps a Ctrl + Z (windows end-of-file).
3. You used WinSCP to copy the file to your Unix box.
4. WinSCP thought: "This has something that's not basic text; I'll put a .bin extension to indicate binary data."
5. The missing __init__.py file (now called __init__.py.bin) means Python doesn't understand toolkit as a package.
6. You create the __init__.py file in the appropriate directory and everything works...?