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
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
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
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
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
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
>>
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.
>
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
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
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
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
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
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
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
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
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
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.
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
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
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,
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
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
24 matches
Mail list logo
