At Florian's suggestion in another thread, I propose that we move further
discussion of the settings refactor to the forum:
https://forum.djangoproject.com/t/settings-refactor/17352
On Wednesday, November 2, 2022 at 2:58:29 PM UTC-4 f.apo...@gmail.com wrote:
> The speckenv example highlights t
The speckenv example highlights the problems when using `literal_eval`:
A=[] will parse as list but A=[a] will parse as string again (if I read the
code correctly). This ambiguity makes it really hard to explain. When using
`literal_eval` one imo has to be consistent and don't fall back to a str
On Tue, Nov 1, 2022 at 10:34 AM Florian Apolloner
wrote:
> Right, that would work. I am wondering though if we want to go all in on a
> typed config object like that or in a first step only have a simple API
> like `config.get('DEBUG', cast=bool)`.
>
>
I found a neat trick in a 12factor library s
config.get is how python-decouple works which is what I use for config and
deployment settings.
On Tuesday, 1 November 2022 at 09:34:15 UTC f.apo...@gmail.com wrote:
> Right, that would work. I am wondering though if we want to go all in on a
> typed config object like that or in a first step o
Right, that would work. I am wondering though if we want to go all in on a
typed config object like that or in a first step only have a simple API
like `config.get('DEBUG', cast=bool)`.
On Tuesday, November 1, 2022 at 3:35:46 AM UTC+1 pe...@lincolnloop.com
wrote:
> On Mon, Oct 31, 2022 at 11:5
On Mon, Oct 31, 2022 at 11:52 AM Florian Apolloner
wrote:
> On Monday, October 31, 2022 at 5:27:02 PM UTC+1 pe...@lincolnloop.com
> wrote:
>
>> In my ideal scenario, the default is a hard-coded settings file for the
>> project (deprecating DJANGO_SETTINGS_MODULE env var) and we have
>> CONFIG_LOA
On Monday, October 31, 2022 at 5:27:02 PM UTC+1 pe...@lincolnloop.com wrote:
> In my ideal scenario, the default is a hard-coded settings file for the
> project (deprecating DJANGO_SETTINGS_MODULE env var) and we have
> CONFIG_LOADERS defined in the settings that could do env, toml, etc.
> Perh
On Sun, Oct 30, 2022 at 7:57 AM Florian Apolloner
wrote:
> Hi Peter,
>
> On Saturday, October 29, 2022 at 6:07:16 PM UTC+2 pe...@lincolnloop.com
> wrote:
>
>> Since you asked for feedback, I'll tell you what I'd do differently (and
>>> this is also a sign that production environment vary widely).
Hey Tobias! Not using DJANGO_SETTINGS_MODULE is due to my personal dislike
of it :)
I don't like the idea of a totally different Python file getting imported
based on an environment variable and I feel like having different Python
files for each environment isn't a great pattern. I think it is easi
Hi Tobias,
On Sunday, October 30, 2022 at 2:02:36 AM UTC+2 tob...@caktusgroup.com
wrote:
> Regarding DJANGO_ENV, why not ship the template with two settings files
> and use the existing DJANGO_SETTINGS_MODULE, instead of adding a new
> environment variable?
>
That is certainly one way to do i
Hi Peter,
On Saturday, October 29, 2022 at 6:07:16 PM UTC+2 pe...@lincolnloop.com
wrote:
> Since you asked for feedback, I'll tell you what I'd do differently (and
>> this is also a sign that production environment vary widely).
>>
>
> Production environments do vary widely, but I don't think t
Hi Pete,
A pluggable backend sounds like a good idea.
Regarding DJANGO_ENV, why not ship the template with two settings files and
use the existing DJANGO_SETTINGS_MODULE, instead of adding a new
environment variable?
Maybe that would be controversial too, I'm not sure, but perhaps less so
than i
On Sat, Oct 29, 2022 at 10:06 AM Peter Baumgartner
wrote:
> Thanks for the thorough review Florian! Some comments inline...
>
> On Wed, Oct 26, 2022 at 1:30 AM Florian Apolloner
> wrote:
>
>> Hi Pete,
>>
>> this does look interesting. And I agree that this is something that would
>> be nice to h
You don't get typing out-of-the-box with straight environment variables.
Handling things like booleans can be tricky. You probably want to handle
"True", "true", "1", "yes", etc. Naive implementations can do the wrong
thing silently and introduce a major security hole (accidentally using
DEBUG=True
Thanks for the thorough review Florian! Some comments inline...
On Wed, Oct 26, 2022 at 1:30 AM Florian Apolloner
wrote:
> Hi Pete,
>
> this does look interesting. And I agree that this is something that would
> be nice to have in core in one form or another. That said I think we have
> to do it
Hi Jure,
My point was mostly about hieracrhy, not the exact format. That said on a
technical level it is true that the same can achieved via python -- after
all this is what settings.py is currently. But the hard truth is that many
people prefer a established configuration file format (for some
IMHO, adding YAML support would introduce a dependency that's not
needed: why not just use Python, instead of ini/yaml/toml?
Projects could have a (.gitignore) env.py that settings.py imports and
then sets the appropriate variables from it. You can use straight
assignment, e.g.
LANGUAGE_C
Hi Pete,
this does look interesting. And I agree that this is something that would
be nice to have in core in one form or another. That said I think we have
to do it iteratively (ie in smaller parts) and evaluate along the way.
Since you asked for feedback, I'll tell you what I'd do differently
I put together a first stab at this at
https://github.com/lincolnloop/django-production. Feedback is appreciated!
On Tue, Aug 23, 2022 at 1:34 PM pe...@lincolnloop.com
wrote:
> I hadn't seen django-simple-deploy. At first glance, it looks interesting,
> but more platform-specific than what I was
I hadn't seen django-simple-deploy. At first glance, it looks interesting,
but more platform-specific than what I was thinking.
I'll play around with creating a third-party app that encapsulates some of
these thoughts and see where I end up.
Thanks for your time and feedback!
On Tuesday, Augus
Hey Pete.
Yes, there can be a lot of steps... (and trouble is every one has a
different opinion once you get to specifics :)
django-webserver looks good — in a similar ballpark to what I had in mind,
yes, but I'd probably not want to bundle the options for each server
myself, as that seems a lot
Thanks for the additional background Carlton! I like the idea of
having some sort of protocol that folks can follow to make
ready-to-use Django server packages (django-webserver [1] is in the
same vein), but I'd strive for more. pip install + INSTALLED_APPS is
great, but getting to production with
Hey Pete.
Yes... this is a good one.
It's difficult to see how we can even have an ASGI runserver in core,
simply because there's no SimpleServer equivalent as there is for WSGI, and
it's not clear one is on the card. (HTTP is getting **more** complex, and I
can't see Python bringing such into t
Hi all! I'd like to re-open the discussion around
https://code.djangoproject.com/ticket/21978
As a "batteries included" framework, Django kind of leaves people to
fend for themselves when it comes to deployment. This makes it harder
than necessary for a developer to go from works-on-my-laptop to
w
24 matches
Mail list logo