How do I adapt my import statements to my folder structure in Django? - django

I just set up a basic folder structure for a new project, however I am doing it a bit different than the standard file structure, since my front-end is in React and will be in a separate git repository. The problem is, my virtual environment is installed in the "backend-django" project and when I try to access my package imports (that I installed in my virtual env) in backend/settings.py it does not recognize them.
As an example: I pip installed django-environ into my venv but when I go to settings.py (like I normally do) and import environ, I get a 'no module named environ' error.
This is my first foray into Django (clearly). For reference, I have previously only used Flask for Python projects. Any help is appreciated!
A mockup of my basic folder structure is here:
folder structure
I have already tried from backend-django import environ and from . import environ. I am still getting the same error.

Related

django - How to manually set sys.path?

Till now I was making change on my django production server (yes, really really bad :p ). I am wanna to go to a git process, and creating a local test server before deployement. So, I downloaded my python files, and ran a :
python manage.py runserver
hoping and prayed... but it was not enough, I got a nice error :
django.core.exceptions.ImproperlyConfigured: WSGI application 'issc.issc.wsgi.application' could not be loaded; Error importing module: 'No module named issc.wsgi'
I read in the documentation that [manage.py] is created automatically and sets up several key parts :
In addition, manage.py is automatically created in each Django project. manage.py is a thin wrapper around django-admin.py that takes care of several things for you before delegating to django-admin.py:
It puts your project’s package on sys.path.
It sets the DJANGO_SETTINGS_MODULE environment variable so that it points to your project’s settings.py file.
It calls django.setup() to initialize various internals of Django.
My question is : how can I manually set up these variables ? Because in my case I downloaded all the files on an arbitrary directory, but it was not enough. Eveything is here, but it is missing the link to this everything....
If you want to manually set the address of your config file, you can set DJANGO_SETTINGS_MODULE with the following:
export DJANGO_SETTINGS_MODULE='settings_to_load'
You can set all your environmental variables this way and it should work. I recommend to use a Virtualenv to this at least.

ImportError when using Haystack 2.0.0 with Django 1.5 and Gunicorn WSGI

I use django-haystack 2.0.0 to index my site, and it has been working great until I upgraded to Django 1.5 and started using the WSGI interface. If I just use the django_gunicorn command it works great, but the Django documentation "highly recommends" I use the gunicorn command.
When I start my site with the gunicorn command, Haystack throws the following error on any page load:
ImportError: cannot import name signals
I have no problems importing signals from the Django or Python shells. I use virtualenv and install all packages locally inside that environment. My wsgi.py file looks just like the default one in the django admin, except that I add the local path to the python path as such:
path = os.sep.join(os.path.abspath(__file__).split(os.sep)[:-2])
if path not in sys.path:
sys.path.append(path)`
Any help you could provide would be very appreciated, thank you!
I don't use gunicorn, but I had the same problem when I used the HAYSTACK_SIGNAL_PROCESSOR setting to point to a custom class that I wrote. That class imported one of my models, which eventually propagated up the import chain, to import my settings module, thus causing a circular import.
When using a setting such as HAYSTACK_SIGNAL_PROCESSOR that points to a class, make sure that class standsalone, and doesn't import either directly or indirectly the Django settings file.

How to deal with heroku renaming my root-level app?

Heroku seems to prefer the apps deployed have a certain structure, mostly that the .git and manage.py is at root level and everything else is below that.
I have inherited a Django app I'm trying to deploy for testing purposes and I don't think I can restructure it so I was wondering if I have an alternative.
The structure I've inherited has most of the files in the root folder:
./foo:
__init__.py,
.git,
Procfile,
settings.py,
manage.py,
bar/
models.py, etc
From within foo I can run python manage.py shell and in there from foo.bar import models works.
However, when I push this to Heroku, it puts the root in /app, so foo becomes app and from foo.bar import models no longer works.
Is there any magic settings that would allow me to indicate that app is really foo and allow me to continue without refactoring the app structure and/or all the imports?
Similar question: I think my question is similar to Heroku - Django: Had to change every mentioning of myproject into app to get my site working. How to best avoid this in the future?, except I'm asking if there's anything I can do without changing the site structure.
You can try adding a line to manage.py that modifies sys.path to make sure that foo is in your path:
import sys
PROJECT_DIR = os.path.abspath(os.path.dirname(os.path.dirname(__file__)))
if PROJECT_DIR not in sys.path:
sys.path.insert(0, PROJECT_DIR)
Although as a side note its not really good django style to have your toplevel directory be a python module, precisely because it makes deployment more complicated (I'm not POSITIVE that the above will work on heroku). I might recommend just changing your code to import from bar directly and removing foo/__init__.py.
The easiest way would be to delete foo/__init__.py and modify your import statements to import from bar instead of from foo, eg
from foo.bar.models import *
becomes
from bar.models import *
Alternatively you can use relative imports. So if you wanted to import bar.models in bar.views, you'd do
from .models import *
The reason this is an issue is that Django 1.4 changed folder structure for newly created projects. Before 1.4 you'd have a similar structure like you described, minus foo/__init__.py. Heroku adapted Django 1.4's project structure, which is arguably better because it encapsulates the settings within the project and makes it more portable.

Django 1.4 config settings

I have been using Django a long time but I recently upgraded to 1.4.
When I created a new project, here is how it was made:
-my_proj
-my_app
-settings.py
-urls.py
-wsgi.py
-venv
-manage.py
-requirements.txt
I am working on my local machine as well as on Heroku. The issue is how I am supposed to refer to modules.
When I am on my local machine, everything seems like it is supposed to be referred to as my_proj.my_app. However, when I am on Heroku, everything has to be referred to as my_app.
Does anyone know of some areas that I should look that might be causing this problem?
Moving your my_app dir to the root directory of your project (where manage.py is located), as it was done in Django tutorial for Django 1.4 will make it a top level module and will allow you to import them just as my_app on your local machine. I would suggest trying this and checking whether Heroku behaves the same.
Alternatively, adding an empty __init__.py, if there there isn't one already, in your my_proj directory might also help Heroku see my_proj as a top-level module, thus allowing you to import your app as my_proj.my_app.
I hope my advice was insightful and helpful.
Good luck!

Imports failing for pylint

I'm testing my project using pylint and currently getting fatal error when importing the internal apps into the project using.
According to pylint, the import should be something like from <appname>.models import ...
as opposed to what I currently have: from <projectname>.<appname>.models import My problem is that when I use the recommended style, the project can't find/import the app. What am I missing here?
Your apps are not in the python path.
Seems like you have a folder for apps, like apps/registration, apps/contact_form etc. and your manage.py is in the folder on top of that one, which has just the project folder.
manage.py does some "magic" by putting all the apps into the python path before starting the server.
If you have custom folder structure, you should edit the manage.py to include your custom apps folder in the python path, preferably as the first element of the python path.