Howdy,
You guys ever seen or used this:
https://pypi.org/project/django-configurations/
Reusable settings. That would be something I would like to see in Django.
On Fri, 28 Feb 2020 at 5:49 AM, Robert Marsanyi wrote:
> I have to say, having settings as Python code is one of the features of
>
I have to say, having settings as Python code is one of the features of
Django for me. Being able to calculate settings values, take advantage of
Python’s module/class parsing, and so on all make settings more than just a
set of dictionary values. I think we would lose a bit of functionality i
Declarative settings, and a lack of a good settings file parsing system,
led me into some rather interesting directions not that long ago.
I maintain an OpenStack project called Adjutant, and I built it on
Django, but ended up using yaml as my config file and having settings.py
read it and pull
Am 01.01.20 um 15:04 schrieb Adam Johnson:
>
> This seems a weird suggest, but when apps depend on another app it
> should be able to override settings for that dependency too
> (because it "uses" that app anyway).
>
>
> It does seem weird to suggest. I haven't seen such a use case mys
ngo/django/blob/c574bec0929cd2527268c96a492d25223a9fd576/django/conf/__init__.py#L171),
after checking the ENVIRONMENT_VARIABLE.
A quick proposal would be to
1. load the environment variable to get the settings name
2. NEW: look for a declarative settings file and load that
3. if
ood
> thing IMHO.
>
> The package manager in Drupal is composer, yes, and together with GDAPS,
> you could use GDAPS Django packages exactly the sameway. Just install it
> using pip/pipenv, and Dajngo/GDAPS finds them automatically.
>
> But this can only be achieved
wouldn't do that. Settings in code/conf files is a good
> thing IMHO.
>
> The package manager in Drupal is composer, yes, and together with GDAPS,
> you could use GDAPS Django packages exactly the sameway. Just install it
> using pip/pipenv, and Dajngo/GDAPS finds them automatic
in Drupal is composer, yes, and together with GDAPS,
you could use GDAPS Django packages exactly the sameway. Just install it
using pip/pipenv, and Dajngo/GDAPS finds them automatically.
But this can only be achieved by adding a line to settings.py (call the
plugin manager), like I did:
https://g
When using settings for my third party packages I use:
* A class to read django.conf.settings and add defaults/other logic through
properties - for example
https://github.com/adamchainz/django-cors-headers/blob/31b9c2ef8a333a40f18081ffc1f1cba9fb34574d/src/corsheaders/conf.py
. This has the benefit
My two cents: JSON isn’t great as a configuration language - It’s annoyingly
picky about some things. YAML or TOML are “better” (for some definition of
better) choices for this domain, in my option. However, Django is historically
quite hesitant about including third party packages and I think i
You have hit a salient point in Django. It indeed is a mess how every third
party
application must add its own configuration classes in order to make their
own
default settings configurable through a settings.py. This results in
settings directives
which can have any attribute name and do not fo
age managers are not frameworks.
Perhaps we could set up a hybrid in which we have a declarative settings file
that can be utilized by a coded settings file, but I feel that might make the
whole system a bit too complex to maintain.
Just my thoughts.
-Original Message-
From: django-develop
Hello,
I recently "finished" my first really working version of GDAPS, my
Generic Django Application Plugin System. It's noway perfect, but does
what it should: providing pluggable apps for an app framework, including
a more or less flexible frontend with each django app.
I had much struggle with
13 matches
Mail list logo
