Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

how to separate INSTALLED_APPS or dev and prod #216

Open
sant527 opened this issue Mar 31, 2019 · 8 comments
Open

how to separate INSTALLED_APPS or dev and prod #216

sant527 opened this issue Mar 31, 2019 · 8 comments
Labels
documentation Improvements or additions to documentation question Further information is requested

Comments

@sant527
Copy link

sant527 commented Mar 31, 2019

In django development i am planning to install django-extensions app

I have to add it to the INSTALLED_APPS.

INSTALLED_APPS = [
    'django.contrib.admin',
    'django.contrib.auth',
    'django.contrib.contenttypes',
    'django.contrib.sessions',
    'django.contrib.messages',
    'django.contrib.staticfiles',
   # third party apps
    'django_extensions',
]

Now how to use django-envion's .env file which will pass INSTALLED_APPS

because i will have a different .env files for dev and prod

@ptink
Copy link

ptink commented Apr 1, 2019

INSTALLED_APPS = [
    'django.contrib.admin',
    ...
] += env.list("ADDITIONAL_APPS", default=[])

dev.env

ADDITIONAL_APPS=devapp1,devapp2,devapp3

prod.env

ADDITIONAL_APPS=prodapp1,prodapp2,prodapp3

Personally INSTALLED_APPS is one of the things I leave to the dev.py / prod.py settings file patterns because the list order is sometimes important but this approach should work for you

@sant527
Copy link
Author

sant527 commented Apr 4, 2019

Personally INSTALLED_APPS is one of the things I leave to the dev.py / prod.py

what does this mean. So how you do it then

@ptink
Copy link

ptink commented Apr 8, 2019

what does this mean. So how you do it then

I have multiple settings files e.g. development.py, production.py, testing.py that all inherit from a base.py settings file. Common settings live in base.py and then dev/prod/testing settings files can override them as per that environments requirements.

see: https://medium.com/django-musings/the-multiple-settings-files-pattern-a6e6066d2a69

@sant527
Copy link
Author

sant527 commented Apr 8, 2019

but then its better to have one settings.py and use django-environ and different .env files

@ptink
Copy link

ptink commented Apr 8, 2019

That's up to you- I prefer a mix of approaches. I only use Django environ to keep sensitive information out of the repository and to read client-specific details from client.env files. Differences in app environments I leave up to separate settings.py files.

@joke2k
Copy link
Owner

joke2k commented Jul 12, 2019

@sant527 @ptink nice discussion,

I fought with this problem a lot of time and I tried always to keep one settings.py to avoid the inheritance of environment specific setting file.

If I can help you with this I suggest using something like ENV=prod or ENV=dev in the .env file, then into the settings.py you can use it to manage the INSTALLED_APPS list:

PRODUCTION = 'prod'
DEVELOPMENT = 'dev'

INSTALLED_APPS = [
    'django.contrib.admin',
    ...
]
if env.str('ENV') == DEVELOPMENT:
  INSTALLED_APPS.append('django_extensions')

in this way, we respecting the settings.py expertness about how to configure a Django application.

A side effect could be if you try to set ENV=dev in a production environment, which could not be found in the development packages. it depends on how to handle the requirements for different environments.

@joke2k joke2k added documentation Improvements or additions to documentation question Further information is requested labels Jul 12, 2019
@sant527
Copy link
Author

sant527 commented Jul 14, 2019

@joke2k
Thank you. I will use that way

what do you mean by

A side effect could be if you try to set ENV=dev in a production environment, which could not be found in the development packages.

@joke2k
Copy link
Owner

joke2k commented Jul 26, 2019

@sant527
is a common practice split requirements.txt by environments.
https://github.com/pydanny/cookiecutter-django/tree/master/%7B%7Bcookiecutter.project_slug%7D%7D/requirements

In this case, using my trick to fast exchange environment with .env ENV variable, you have to be sure that the INSTALLED_APPS are really installed.
Very common example: you could have django-debug-toolbar not installed in production, but changing ENV to dev you'll raise an error with this code in settings.py:

if env.str('ENV') == DEVELOPMENT:
  INSTALLED_APPS.append('debug_toolbar')

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
documentation Improvements or additions to documentation question Further information is requested
Projects
None yet
Development

No branches or pull requests

3 participants