Re: Making startproject's settings more 12-factor-y

Comments like these are inappropriate for this mailing list. Stop spamming your whatsapp number all over the place. On Sunday, July 26, 2020 at 6:00:47 PM UTC+2 mithileshr...@gmail.com wrote: > ok whatsapp +918709440658 <+91%2087094%2040658> > > On Fri, 10 Jul 2020, 2:54 pm '1337 Shadow Hacker'

Re: Making startproject's settings more 12-factor-y

ok whatsapp +918709440658 On Fri, 10 Jul 2020, 2:54 pm '1337 Shadow Hacker' via Django developers (Contributions to Django itself), wrote: > All right, thank you for your feedback. > > May I throw in the idea of using DJ_ instead of DJANGO_ as prefix ? > > -- > You received this message because

Re: Making startproject's settings more 12-factor-y

All right, thank you for your feedback. May I throw in the idea of using DJ_ instead of DJANGO_ as prefix ? -- 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

Re: Making startproject's settings more 12-factor-y

LOL On 7/8/20, Kye Russell wrote: > Lol. > > > On 8 July 2020 at 10:00:11 am, Divyesh Khamele > (pythonmatedivy...@gmail.com) > wrote: > > Hi Charles, > Divyesh here,have 4+ years of experience to work as a Django developer. I > can help you on this. > > You need to hire me. > > Hourly rate:

Re: Making startproject's settings more 12-factor-y

Lol. On 8 July 2020 at 10:00:11 am, Divyesh Khamele (pythonmatedivy...@gmail.com) wrote: Hi Charles, Divyesh here,have 4+ years of experience to work as a Django developer. I can help you on this. You need to hire me. Hourly rate: 8$/hr. Best, D On Wednesday, 8 July 2020, Carles Pina i

Re: Making startproject's settings more 12-factor-y

Hi Charles, Divyesh here,have 4+ years of experience to work as a Django developer. I can help you on this. You need to hire me. Hourly rate: 8$/hr. Best, D On Wednesday, 8 July 2020, Carles Pina i Estany wrote: > > Hi, > > I haven't read all this thread in detail and I might go off-topic.

Re: Making startproject's settings more 12-factor-y

Hi, I haven't read all this thread in detail and I might go off-topic. Sorry about that. On Jul/07/2020, '1337 Shadow Hacker' via Django developers (Contributions to Django itself) wrote: > Do we really need DJANGO_ prefix on env vars ? In my first years of I know when having a variable

Re: Making startproject's settings more 12-factor-y

Not everyone runs containerized. I think some settings shouldn't be prefixed--i.e. DATABASE_URL is a pretty common one. -A On Tue, Jul 7, 2020 at 12:40 AM '1337 Shadow Hacker' via Django developers (Contributions to Django itself) wrote: > Do we really need DJANGO_ prefix on env vars ? In my

Re: Making startproject's settings more 12-factor-y

Do we really need DJANGO_ prefix on env vars ? In my first years of practicing 12-factor I used such prefix, but the last 5-6 years I let it go, because I just ended up with a list full of DJANGO_ variables in a containerized where only Django is running. -- You received this message because

Re: Making startproject's settings more 12-factor-y

Thanks for the discussion all, and PRs. Lots of different perspectives. * Florian's draft PR looks more or less right, so we should be able to eliminate the need to specify a SECRET_KEY if you're not going to use it. * I opened #31757 to capture

Re: Making startproject's settings more 12-factor-y

As promised the PR: https://github.com/django/django/pull/13120 I also had to touch TokenResetGenerator since it stores the secret in a class level variable and that would prevent the server startup either way… Let's see what the full test suite says, but I cannot really imagine many issues.

Re: Making startproject's settings more 12-factor-y

On Sunday, June 28, 2020 at 1:23:25 AM UTC+2 timog...@gmail.com wrote: > It seems like it could be insecure to move that to a system check as "For > performance reasons, checks are not run as part of the WSGI stack that is > used in deployment." (Also, it seems impossible to write a system

Re: Making startproject's settings more 12-factor-y

> > There is no reason Django should complain a missing secret key when it > does not need one at all. I agree with this. It is an extra step in making really basic apps that don't use any encryption functionality. IIRC, the "Django needs a secret key" check has always been a custom check rather

Re: Making startproject's settings more 12-factor-y

Hi Tom, On Friday, June 26, 2020 at 12:43:19 PM UTC+2 t...@carrick.eu wrote: > I do have a use-case where having a default SECRET_KEY makes things much > easier - docker. > > Normally you can't run management commands in a Dockerfile if there's no > secret key (and often other things) set, and

Re: Making startproject's settings more 12-factor-y

I do have a use-case where having a default SECRET_KEY makes things much easier - docker. Normally you can't run management commands in a Dockerfile if there's no secret key (and often other things) set, and usually it's best to run collectstatic as a build step. So your options end up being:

Re: Making startproject's settings more 12-factor-y

Hello, On Fri, 26 Jun 2020 00:46:02 -0700 (PDT) Florian Apolloner wrote: > On Thursday, June 25, 2020 at 7:52:31 PM UTC+2 kit@gmail.com > wrote: > > > Personally, I think that *at minimum* providing Django-builtin "get > > from env" helpers would be great; beyond that, I'd love to have >

Re: Making startproject's settings more 12-factor-y

Hi, On 6/26/20 12:11 PM, René Fleschenberg wrote: > geared towards development (random default value for SECRET_KEY, DEBUG = > False). I meant DEBUG = True here, of course :) -- René Fleschenberg -- You received this message because you are subscribed to the Google Groups "Django developers

Re: Making startproject's settings more 12-factor-y

Hi Flo, > And there are plenty more things to consider; for instance I do not > agree that it makes sense to have "SECRET_KEY" default to a value when > missing in the env. It is way to easy to type "SECRT_KEY" and never > realize that. So if "SECRET_KEY" is taken from the environment it should >

Re: Making startproject's settings more 12-factor-y

> > i dont belive in adding default names to environment variables, they're up > to the user to define > Javier, I think you missed what Florian was talking about. He was suggesting there shouldn't be default *values* for some settings. > I personally rather have no solution in Django itself

Re: Making startproject's settings more 12-factor-y

Hi Florian, thank for your input, i dont belive in adding default names to environment variables, they're up to the user to define. Nothing will be given by default, you need the SECRET_KEY? `from_env` has no idea what that means, its just another name, so you tell it what it will do with this

Re: Making startproject's settings more 12-factor-y

Hi there, On Thursday, June 25, 2020 at 7:52:31 PM UTC+2 kit@gmail.com wrote: > Personally, I think that *at minimum* providing Django-builtin "get from > env" helpers would be great; beyond that, I'd love to have them be > included around `DEBUG` and `SECRET_KEY` with the current values

Re: Making startproject's settings more 12-factor-y

Hi Carsten, great question! The idea as i see it is: having the least amount of moving parts the better. The trick here is unification, keep a single settings file with 99% of the configuration needed using environment variables/secrets/zookeeper/etc to swap out environment specific options

Re: Making startproject's settings more 12-factor-y

Hello, Am 25.06.20 um 19:51 schrieb Kit La Touche: > […] Once we see how this gets used, we can see about passing it a file > instead of `os.environ`, […] This is probably a stupid question, but what is the advantage of this (and env vars) over this: In project_dir/project_dir: settings.py

Re: Making startproject's settings more 12-factor-y

Think of it like this, you make a simple settings/base.py where you define something like this: from django.conf import from_env MEDIA_PATH = '/mnt/media' # hardcoded to show you don't have to use ` from_env` DEBUG = from_env.bool('DEBUG') SECRET_KEY = from_env('SECRET_KEY') DATABASES = {

Re: Making startproject's settings more 12-factor-y

If you at least don’t separate all variables that are dependent on the environment from the settings.py, then you’re going to have to edit your settings.py file anyways, defeating the purpose of this. Database and Cache connection settings are clearly dependent on the environment. -bobby > On

Re: Making startproject's settings more 12-factor-y

A small incremental change with some Django helpers and showing their use in the default settings.py is a great step forward, I would be +1 on that. Tom > On 25 Jun 2020, at 18:52, Kit La Touche wrote: > >  > Wow, `distutils.util.strtobool` is great to know about! > > So, can we refocus

Re: Making startproject's settings more 12-factor-y

Wow, `distutils.util.strtobool` is great to know about! So, can we refocus this conversation? This is starting to look like previous conversations on this topic, which pull in a lot of possibilities but don't lead to a change. How do we go about generating a DEP or other consensus-building tool

Re: Making startproject's settings more 12-factor-y

Hi Bobby, yes, thank you, this looks around the line of what i would like us to implement in Django. Side note: i saw this config('DEBUG', default=False, cast=bool) and thought "there is NO WAY that works", that led me to from distutils.util import strtobool, absolute mind blown! Thanks!

Re: Making startproject's settings more 12-factor-y

There’s also python-decouple that I use that I haven’t seen mentioned in this thread. It lets you set specific environment variables in a separate .env file or INI file: https://github.com/henriquebastos/python-decouple -bobby > On Jun 25, 2020, at 4:47 AM, Javier Buzzi wrote: > > Hey Tom,

Re: Making startproject's settings more 12-factor-y

Hey Tom, cool project haven't heard of it, looks to me more inline with validating and converting user input from an api/form. I could really see myself using this in my personal projects, however this looks like we'd be going back to the class based configuration that im trying to avoid.

Re: Making startproject's settings more 12-factor-y

Javier, I just wanted to point out another option for configuration: pydantic - it offers a very slick and intuitive interface for settings management across environments, seamless handing of environment variables by using type hints, and so on. I wouldn't

Re: Making startproject's settings more 12-factor-y

This makes sense, I have a project that has a lot of settings files that get activated depending on the value of DJANGO_SETTINGS_MODULE. The solution i outlined above takes your reservations under consideration, if you want to use it, great, if not also great -- its a supplement not a

Re: Making startproject's settings more 12-factor-y

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,

Re: Making startproject's settings more 12-factor-y

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

Re: Making startproject's settings more 12-factor-y

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

Re: Making startproject's settings more 12-factor-y

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

Re: Making startproject's settings more 12-factor-y

There are plenty of project templates out there that offer more fully-featured starting points. It's generally agreed that's out-of-scope for the provided startproject template. But could we make it easier to use environment variables in the default template? That seems like a reasonable

Re: Making startproject's settings more 12-factor-y

I also have my own version of “startproject" that creates several additional files, including my web server config file (I use H20 web server, not Nginx) as well as a uWSGI vassals config file. I create the following preconfigured files and directories using a command-line Python script:

Re: Making startproject's settings more 12-factor-y

I saw what you added; I tried to make this a minimal change, and was conscious also Carl's expressed preference (which I share, tbh) in the linked discussion for less-magic. I figured a function that just parsed values out of the env would be the smallest possible first step, so I'm inclined to

Re: Making startproject's settings more 12-factor-y

I think its great, but id add a little more customizability. I've added an example to your PR. -- 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

Re: Making startproject's settings more 12-factor-y

I have put in a PR (https://github.com/django/django/pull/13029) that I think matches pretty well with the comments from Carl Meyer in the conversation you linked. Please let me know what you think of it. It adds a small helper function that will read an env var, optionally coercing it to a type,

Re: Making startproject's settings more 12-factor-y

I have, thank you! I tried to do my research before I wrote this email and this PR, but there's a ton of context to all those conversations that I'm sure I'd be missing, so I'm never gonna reach the point of feeling confident that I have a handle on what's gone before, alas. On Fri, Jun 5, 2020

Re: Making startproject's settings more 12-factor-y

Have you read past discussions on the mailing list? For example: Making Django more PaaS-friendly https://groups.google.com/d/topic/django-developers/BAGhOKXGj4I/discussion Searching the archives for "12-factor" yields some other results. That may help you to craft your proposal. On Friday,

Making startproject's settings more 12-factor-y

I'm interested in reducing the distance from running `startproject` to having a deployable Django app, having recently had a number of interactions with junior devs interested in using Django but finding deployment a nightmare. Some of this is of course on the other side, on the PaaS of choice,