Those are valid concerns, and I want to especially come back to "all of this has to be optional, which seems to rule out making it part of the starting project template".
But first, I want to reiterate that what's vital to me (and this may be only my concern, of course!) is that newer developers, especially folks without an ops team and without ops experience, have a clearer path to deployment. Partly this is selfish: I want Django to grow and flourish, and I think that giving new folks a good experience with it their first time will facilitate that. Folks with an ops team can already be assumed to have people to talk with and work with to negotiate and understand their particular deployment context. So, in light of that, coming back to "has to be optional", I agree—I very much agree. However, I think it also has to be *visible*. That was my motivation for, in my proposed PR, including it in the default `settings.py` template, but making sure defaults were set to the values they would be without the addition of `from_env`. I'm not sure at all that that's the best way, but that was my thought process! "Optional" means a few things, and I think that there's a difference between "setting env vars should be optional" and "using `from_env` should be optional" and "having `from_env` ever be in your `settings.py` should be optional", and I'd love to clarify which part of that spectrum most closely aligns to your intent. Cheers, --Kit On Wed, Jun 24, 2020 at 3:24 PM Dan Davis <[email protected]> wrote: > tMost of the world is not as seamless as heroku. My DevOps won't give me > any more than a handful of environment variables. I wanted something like > DATABASE_URL, but all I have is DJANGO_LOG_DIR and DJANGO_SETTINGS_MODULE, > and so I need many, many settings files. I think that happens a lot, and > maybe a common pattern. > > From a 12factor perspective, I would like to get it down to local settings > (development) and production settings - yet for a lot of users, DevOps is > not really supporting a full PaaS-like experience any way. > > So - all of this has to be optional, which seems to rule out making it > part of the starting project template. For sure, I've got my personal > template, and work has an on-premise template and a Cloud template as well > - but the department of developers doesn't always use these. I find > databases containing the tables for other projects, long after the models > and migrations are gone, indicating a start by copy mode. > > On Wed, Jun 24, 2020 at 1:35 PM Kit La Touche <[email protected]> wrote: > >> Carlton—thanks very much for the feedback. Javier—likewise. In >> particular, the imagined API you describe above is very appealing to me: >> start with `from_env` and then if you learn more about this and want to, >> add in some `EnvFileLoader`. >> >> I want to make clear my motivation and agenda here: I have recently had >> some conversations with newer devs about their experiences with deployment >> of apps they're working on, and with a friend at Heroku about his informal >> research into the problems people have with the same. One recurring >> friction point (and this is not just on Heroku at all, to be clear) is that >> there are a number of things that people *don't know they need to >> configure* for a working deployment. >> >> There are four settings that are recurring particular gotchas that people >> miss: the secret key, debug, static files, and databases. Static files >> seems big and out of scope, databases seems adequately handled by >> dj-database-url for most cases, and if your case is more complex, you'll >> learn it, but the other two (secret key and debug) seemed easy enough to >> flag as "you probably need to configure these!" with this sort of change to >> settings. This would be a first step towards shortening the distance from >> `startproject` to a working deployment. >> >> Newer devs in particular have, based on my conversations and this >> friend's research, been unlikely to (a) know that there are different >> `startproject` templates, and (b) feel equipped to choose one, if they do >> know. >> >> My hope is to make the smallest possible change to just start us moving >> towards more clearly flagging, especially for newer devs, "these are things >> that will need additional configuration in order to move from 'works on my >> machine' to 'deployed'." >> >> Towards that end, I thought that adding a "you might want to get this >> from the env" helper would be a clear indication to a new dev that this is >> a matter to even consider. Adding other configuration-getting options like >> different secret-store file backends seems like a good next step. >> >> Thanks, >> >> --Kit >> >> On Wed, Jun 24, 2020 at 11:13 AM Javier Buzzi <[email protected]> >> wrote: >> >>> I looked at the libs that do what we want: >>> >>> django-configurations - it looks like they use environment variables / >>> either via loading them from the environ or a key/value pair file. Having >>> classes inside the settings.py might be weird to people.. at the least very >>> different. >>> confucius - very simplistic, only supports environ and is classed based, >>> similar to django-configurations. >>> django-environ - supports env file and environ, non-class based. >>> dynaconf - supports all kinds of loading options (toml, json, ini, >>> environ, .env +) non-class based. >>> >>> In my opinion, django-environ and dynaconf would be the easiest to sell >>> to the community, it would require the least changes/paradigm shifts from >>> how everyone is already using django. >>> >>> Personally, i would really like to see something like this inside my >>> settings.py: >>> >>> from django.conf import from_env # using standard os.environ >>> >>> DEBUG = from_env.bool("DEBUG", default=False) >>> >>> DATABASES = { >>> "default": from_env.db("DATABASE_URL") # crash if it cant find it >>> } >>> >>> ... >>> >>> for more complex examples: >>> >>> from django.conf import EnvFileLoader >>> >>> from_env = EnvFileLoader("path/to/.secret") >>> >>> ... >>> >>> We can have how ever many loaders we want: toml, json, ini .. >>> >>> This is both borrowing heavily from dynaconf and django-environ, making >>> the fewest changes to how people are accustomed to doing things. >>> >>> .. what do you guys think? >>> >>> - Buzzi >>> >>> -- >>> You received this message because you are subscribed to the Google >>> Groups "Django developers (Contributions to Django itself)" group. >>> To unsubscribe from this group and stop receiving emails from it, send >>> an email to [email protected]. >>> To view this discussion on the web visit >>> https://groups.google.com/d/msgid/django-developers/41cea044-ffe1-445d-ab7a-a65f69e6d85ao%40googlegroups.com >>> <https://groups.google.com/d/msgid/django-developers/41cea044-ffe1-445d-ab7a-a65f69e6d85ao%40googlegroups.com?utm_medium=email&utm_source=footer> >>> . >>> >> -- >> You received this message because you are subscribed to the Google Groups >> "Django developers (Contributions to Django itself)" group. >> To unsubscribe from this group and stop receiving emails from it, send an >> email to [email protected]. >> To view this discussion on the web visit >> https://groups.google.com/d/msgid/django-developers/CAFcS-hDn0AFW4dj_-secrMGq-iWYz-TWKG-vw9%3DVmZ3L6j04aA%40mail.gmail.com >> <https://groups.google.com/d/msgid/django-developers/CAFcS-hDn0AFW4dj_-secrMGq-iWYz-TWKG-vw9%3DVmZ3L6j04aA%40mail.gmail.com?utm_medium=email&utm_source=footer> >> . >> > -- > You received this message because you are subscribed to the Google Groups > "Django developers (Contributions to Django itself)" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [email protected]. > To view this discussion on the web visit > https://groups.google.com/d/msgid/django-developers/CAFzonYZc%3DqjMM%2BeQ3QTQ4XJfQwAkJzxU-to8SVxiuDJJjiHy_A%40mail.gmail.com > <https://groups.google.com/d/msgid/django-developers/CAFzonYZc%3DqjMM%2BeQ3QTQ4XJfQwAkJzxU-to8SVxiuDJJjiHy_A%40mail.gmail.com?utm_medium=email&utm_source=footer> > . > -- You received this message because you are subscribed to the Google Groups "Django developers (Contributions to Django itself)" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/CAFcS-hAh_eRLd6fgw%2B_akMC5TUZOEsBv_dcBy2e5AaHZGr-XZw%40mail.gmail.com.
