We Keep Coding

Flask server does not recognize my own imported module (ModuleNotFoundError)

In my main Python file, I import another script of mine called helper_1.py (from the subfolder my_helpers) like this:
from my_helpers.helper_1 as h1
However, when I now try to start my server (or deploy it to Heroku), the server will crash with the error notice:
ModuleNotFoundError: No module named 'my_helpers'
I do have a Procfile, requirements.txt, runtime.txt, and wsgi.py.
The content of my wsgi.py is:
from app.main import app
if __name__ == "__main__":
app.run()
MY QUESTION:
Where and how do I have to declare my custom modules (own scripts) so they are properly detected when starting the Flask server?
Everything works fine if I leave out the external reference to my custom module.

The folder my_helpers needs to be a package. To do this put an __init__.py file inside the my_helpers folder. This maybe fix your problem.

Django No Module Named With Inner Package Using

I want to write my own python package inside django's app. It looks like that: I have secondary app. It totally works except one thing. Someday I'd decided to make my app more structured. And there where problems started. First of all, I've added python package(with simple init.py inside directory) to the app. Then I've added second package inside that package. And when I try to run django.setup() inside packages' files, I'm getting this error: ModuleNotFoundError: No module named '<primary settings container module name goes here>'
How to make my custom package's functions working properly?

The problem is that settings module isn't "viewable" from your package, e.g. you should add the location of main directory to PATH variable, which could be done like this:
from sys import path
from pathlib import Path
path.append(str(Path(__file__).resolve().parent))
Or you can simply add it permanently to system PATH.

Complex Python Bottle App + WSGI

I have a python bottle application inside of a single folder that's been organized by function and I would like to convert my existing cherrypy usage over to apache mod_wsgi.
The folder structure looks like the following:
- project
-- app.py (loads the webserver class and runs it)
-- app
--- common
--- logs
--- modules
--- tools
--- web
---- webserver.py
The reason for this structure was so code from common could be used within tools and web without any issue. Imports are all done in a style of "from app.common.blah import utility". When trying to setup mod_wsgi, it expects to load up a simple application.
Is it possible to run mod_wsgi with a folder structure like this? If not, are there any recommendations for setting up a structure that will allow for mod_wsgi, but also the sharing of common utilities between folders like tools and web?

From the Bottle deployment docs on Deployment:
All you need is an app.wsgi file that provides an application object. This object is used by mod_wsgi to start your application and should be a WSGI-compatible Python callable.
File /var/www/yourapp/app.wsgi:
import os
# Change working directory so relative paths (and template lookup) work again
os.chdir(os.path.dirname(__file__))
import bottle
# ... build or import your bottle application here ...
# Do NOT use bottle.run() with mod_wsgi
application = bottle.default_app()
In your case, edit the snippet above to import the application object that is presumably defined in your app.py

Import a module from the root

In this structure:
app
-companies
--models.py
--__init__.py
-manage.py
-__init__.py
models.py
class Company():
pass
manage.py
from flask import Flask
app = Flask(__name__)
from app.companies.models import Company
if __name__ == '__main__':
manager.run()
ImportError: No module named app.companies.models
What is the reason? In the views.py, inside the companies folder, the import works without any problem.

The problem is not with your code, but with how you're running it:
I am running python manage.py
For this to work, your working directory must be app. The current working directory is automatically added to your sys.path. There are two possibilities here, both of them bad:
The more likely is that the directory containing app isn't on sys.path at all, so as far as Python is concerned, there is no top-level package named app.
The less likely is that the directory containing app is on sys.path, as well as app itself. In that case, you will confuse the hell out of the importer, because the same file or directory can end up imported as two or more separate objects with different names in sys.modules. It's hard to predict exactly what problems that can cause, but it will cause problems.
Either way, the solution is to not run it that way. Instead, run it from one directory up, the directory that app is in. Which means you have to run it one of the following ways:
python -m app.manage
python app/manage.py

Sys.path modification or more complex issue?

I have problems with importing correctly a module on appengine. My app generally uses django with app-engine-patch, but this part is task queues using only the webapp framework.
I need to import django settings for the app to work properly.
My script starts with:
import os
import sys
sys.path.append('common/')
# Force Django to reload its settings.
from django.conf import settings
settings._target = None
# Must set this env var before importing any part of Django
os.environ['DJANGO_SETTINGS_MODULE'] = 'settings'
I always get this error, or something related:
<type 'exceptions.ImportError'>: No module named ragendja.settings_pre
because the settings.py file starts with
from ragendja.settings_pre import *
I think I need to add ragendja to sys.path again but I had several tries that didn't work.
Here is my directory:
project/
app.yaml
setting.py
common/
appenginepatch/
ragendja/
setting_pre.py
myapp/
script.py
Is it only a sys.path problem and how do I need to modify it with the correct syntax?
Thanks

App engine patch manipulates sys.path internally. Background tasks bypass that code, so your path will not be ready for Django calls. You have two choices:
Fix the paths manually. The app engine documentation (see the sub-section called "Handling import path manipulation") suggests factoring the path manipulation code into a module that can be imported by your task script.
Eliminate dependencies on django code, if possible. If you can write your task to be pure python and/or google api calls, you're good to go. In your case, this might mean refactoring your settings code.

Why not:
sys.path.append('common/appenginepatch')
since the ragendja is in this directory?