Re: Fellow Reports - December 2019

[Mariusz Felisiak]

Week ending December 29, 2019.

*Triaged:*
https://code.djangoproject.com/ticket/31116 - Running test in parallel 
seems broken. (invalid)
https://code.djangoproject.com/ticket/31115 - ORM generates wrong alias for 
subquery. (fixed)
https://code.djangoproject.com/ticket/31117 - ThreadTests fails due to 
double test_ prefix caused by TestDbCreationTests. (accepted)
https://code.djangoproject.com/ticket/31122 - Clarify how the Lookup class 
follow the Query Expression API. (accepted)
https://code.djangoproject.com/ticket/31124 - Model.get_FOO_display() does 
not work correctly with inherited choices. (needsinfo)
https://code.djangoproject.com/ticket/31118 - FileInput shouldn't display 
required attribute when initial data exists. (accepted)
https://code.djangoproject.com/ticket/31124 - Model.get_FOO_display() does 
not work correctly with inherited choices. (accepted)

*Reviewed/committed:*
https://github.com/django/django/pull/12241 - Fixed #31109 -- Disabled 
grouping by aliases on QuerySet.exists().
https://github.com/django/django/pull/12088 - Fixed #30998 -- Added 
ModelChoiceIteratorValue to pass the model instance to 
ChoiceWidget.create_option().
https://github.com/django/django/pull/12252 - Fixed #31121 -- Cleared Site 
cache in SitesFrameworkTests.
https://github.com/django/django/pull/12246 - Fixed #31114 -- Fixed 
HttpRequest.build_absolute_uri() crash with reverse_lazy() locations.

Best regards,
Mariusz

-- 
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 django-developers+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/585048f5-b3fe-4de3-987f-ea6ef698af2d%40googlegroups.com.

declarative settings

[Christian González]

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 it, and one of the lessons I learned was
Django's setup system, and how it deals with loading apps. Unfortunately
Django can't load/unload apps on the fly, so it is necessary to restart
Django whenever a new GDAPS app is installed via pip.

But: I want to resurrect an old theme again which would, in a way,
improve some of the loading problems I encountered. Django's settings
are code. Which is, in fact, a very good thing, as it makes it extremely
flexible and adaptable to different setups. But, as discussed with the
SECRET_KEY here, some of the settings _have_ to be coded very
complicated, and it makes some things like per-app-settings extremely
uncomfortable.

What if - and please don't kill me instantly - yes, I am a newcomer, and
not a good programmer maybe - but some things are viewed better from
"outside" - what if Django settings could be "declarative"?

So instead of Python code like

INSTALLED_APPS = [
    'django.contrib.admin',
    'django.contrib.auth',
    'django.contrib.contenttypes'
]

This would be in an e.g. JSON file

{

    "INSTALLED_APPS": [
        "django.contrib.admin",
        "django.contrib.auth",
        "django.contrib.contenttypes"
    ] ,
    ROOT_URLCONF: "fooproject.urls"
}

Django's settings.py would look different: It would load that
settings.json file and set the appropriate values into local code - so
this wouldn't make much difference.

Except 2 things:

1. Apps could have (default) settings, and they could be merged MUCH
easier. Things like namespaced classes that are overwriting values like
DRF/graphene does, would be completely unnecessary. The main
settings.json file could be the "last word" in the process of settings,
so anything an app would suggest could be overrided in the main file.

2. Installed apps could be managed much more comfortable. Adding an app
could be done by a script (JSON editing is easy. Editing code
(=settings.py) is error prone and uncomfortable). I have a Django
command script ATM for that, but just because I add a line into
settings.py to add some additional apps to the list.

This even could be done with backwards compatibility, because Django
would keep it's settings.py file optionally:

* read json settings (if they exist), use them
* load settings.py which allows to override them again (using some
special code tricks like dynamic loading, environments etc.)

Please tell me what you think about that.

Christian


-- 
Dr. Christian González
https://nerdocs.at

-- 
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 django-developers+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/3047a7b6-3fa0-d574-4bb6-7842b7aed44a%40nerdocs.at.


pEpkey.asc
Description: application/pgp-keys

RE: declarative settings

[Matthew Pava]

It's an interesting idea, and I'm not opposed to it myself; however, keeping 
the settings as Python code is not an abnormal practice compared to other 
software.

I've been working with some Drupal stuff lately, and it is written in PHP. 
Drupal is a content management system that can be extended with various modules 
written in PHP. It's settings file is also just a code file of PHP. Drupal does 
take advantage of a package manger called composer, which would be similar to 
our pipenv. Both of those managers use JSON files for their appropriate 
settings. But package 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-developers@googlegroups.com 
[mailto:django-developers@googlegroups.com] On Behalf Of Christian González
Sent: Monday, December 30, 2019 4:46 PM
To: django-developers
Subject: declarative settings

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 it, and one of the lessons I learned was Django's 
setup system, and how it deals with loading apps. Unfortunately Django can't 
load/unload apps on the fly, so it is necessary to restart Django whenever a 
new GDAPS app is installed via pip.

But: I want to resurrect an old theme again which would, in a way, improve some 
of the loading problems I encountered. Django's settings are code. Which is, in 
fact, a very good thing, as it makes it extremely flexible and adaptable to 
different setups. But, as discussed with the SECRET_KEY here, some of the 
settings _have_ to be coded very complicated, and it makes some things like 
per-app-settings extremely uncomfortable.

What if - and please don't kill me instantly - yes, I am a newcomer, and not a 
good programmer maybe - but some things are viewed better from "outside" - what 
if Django settings could be "declarative"?

So instead of Python code like

INSTALLED_APPS = [
    'django.contrib.admin',
    'django.contrib.auth',
    'django.contrib.contenttypes'
]

This would be in an e.g. JSON file

{

    "INSTALLED_APPS": [
        "django.contrib.admin",
        "django.contrib.auth",
        "django.contrib.contenttypes"
    ] ,
    ROOT_URLCONF: "fooproject.urls"
}

Django's settings.py would look different: It would load that settings.json 
file and set the appropriate values into local code - so this wouldn't make 
much difference.

Except 2 things:

1. Apps could have (default) settings, and they could be merged MUCH easier. 
Things like namespaced classes that are overwriting values like DRF/graphene 
does, would be completely unnecessary. The main settings.json file could be the 
"last word" in the process of settings, so anything an app would suggest could 
be overrided in the main file.

2. Installed apps could be managed much more comfortable. Adding an app could 
be done by a script (JSON editing is easy. Editing code
(=settings.py) is error prone and uncomfortable). I have a Django command 
script ATM for that, but just because I add a line into settings.py to add some 
additional apps to the list.

This even could be done with backwards compatibility, because Django would keep 
it's settings.py file optionally:

* read json settings (if they exist), use them
* load settings.py which allows to override them again (using some special code 
tricks like dynamic loading, environments etc.)

Please tell me what you think about that.

Christian


--
Dr. Christian González
https://nerdocs.at

--
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 django-developers+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/3047a7b6-3fa0-d574-4bb6-7842b7aed44a%40nerdocs.at.

-- 
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 django-developers+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/8ea6a5cda5f64ff6babaaf3e42fa9629%40iss2.ISS.LOCAL.

Re: declarative settings

[Jacob Rief]

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 follow any namespacing.

Some external apps, such as easy-thumbnails 
 add their own configuration 
framework 

with many different setting attributes, while others such as DRF use one 
Python dictionary
to keep all configurations in one closed namespace. The latter in my 
opinion is the
better approach but has its own issues. Having a consistent naming 
convention of setting
attributes, and a reconfiguration framework would certainly be beneficial 
in Django.

In my opinion, just switching to JSON does not resolve these naming 
convention issues,
but adds a bunch of other problems:

*Some configuration settings must be lazy.*
For instance, ugettext_lazy is used very often in the setting.py. This 
can't be handled by JSON.

*Writing JSON by hand is harder than writing Python.*
An alternative would be the usage of yaml or toml.

*Some settings must be taken from the environment.*
Especially database passwords and the SECRET_KEY shall be injected through 
the environment.
Typically here one would use os.getenv('DJANGO_SECRET_KEY') or similar. 
This can't be
handled by JSON either.

On Monday, December 30, 2019 at 11:46:03 PM UTC+1, Christian González wrote:
>
>
> * read json settings (if they exist), use them 
> * load settings.py which allows to override them again (using some 
> special code tricks like dynamic loading, environments etc.) 
>
>
If implemented, wouldn't it make more sense to use a JSON file to override 
a settings.py
rather than doing it vice versa? 

– just my two cents,
Jacob

-- 
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 django-developers+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/f5d9a23a-2927-454e-a3d3-6d2361c3aa06%40googlegroups.com.

Re: declarative settings

[Tom Forbes]

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 including a 
TOML or YAML parser even as an optional dependency might not be the way forward.

So rather than just “allowing people to use JSON files for settings” it would 
be very interesting to explore what a pluggable settings backend would look 
like. It seems that work in this area would be best spent on a general 
abstraction rather than a specific one. There was some discussion around this 
idea in the GSOC thread and I’m sure it’s come up before. Personally I think 
configuration management is an area of Django that is quite underdeveloped 
compared to other frameworks.

> On 30 Dec 2019, at 22:46, Christian González  
> wrote:
> 
> 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 it, and one of the lessons I learned was
> Django's setup system, and how it deals with loading apps. Unfortunately
> Django can't load/unload apps on the fly, so it is necessary to restart
> Django whenever a new GDAPS app is installed via pip.
> 
> But: I want to resurrect an old theme again which would, in a way,
> improve some of the loading problems I encountered. Django's settings
> are code. Which is, in fact, a very good thing, as it makes it extremely
> flexible and adaptable to different setups. But, as discussed with the
> SECRET_KEY here, some of the settings _have_ to be coded very
> complicated, and it makes some things like per-app-settings extremely
> uncomfortable.
> 
> What if - and please don't kill me instantly - yes, I am a newcomer, and
> not a good programmer maybe - but some things are viewed better from
> "outside" - what if Django settings could be "declarative"?
> 
> So instead of Python code like
> 
> INSTALLED_APPS = [
> 'django.contrib.admin',
> 'django.contrib.auth',
> 'django.contrib.contenttypes'
> ]
> 
> This would be in an e.g. JSON file
> 
> {
> 
> "INSTALLED_APPS": [
> "django.contrib.admin",
> "django.contrib.auth",
> "django.contrib.contenttypes"
> ] ,
> ROOT_URLCONF: "fooproject.urls"
> }
> 
> Django's settings.py would look different: It would load that
> settings.json file and set the appropriate values into local code - so
> this wouldn't make much difference.
> 
> Except 2 things:
> 
> 1. Apps could have (default) settings, and they could be merged MUCH
> easier. Things like namespaced classes that are overwriting values like
> DRF/graphene does, would be completely unnecessary. The main
> settings.json file could be the "last word" in the process of settings,
> so anything an app would suggest could be overrided in the main file.
> 
> 2. Installed apps could be managed much more comfortable. Adding an app
> could be done by a script (JSON editing is easy. Editing code
> (=settings.py) is error prone and uncomfortable). I have a Django
> command script ATM for that, but just because I add a line into
> settings.py to add some additional apps to the list.
> 
> This even could be done with backwards compatibility, because Django
> would keep it's settings.py file optionally:
> 
> * read json settings (if they exist), use them
> * load settings.py which allows to override them again (using some
> special code tricks like dynamic loading, environments etc.)
> 
> Please tell me what you think about that.
> 
> Christian
> 
> 
> --
> Dr. Christian González
> https://nerdocs.at
> 
> --
> 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 django-developers+unsubscr...@googlegroups.com.
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/django-developers/3047a7b6-3fa0-d574-4bb6-7842b7aed44a%40nerdocs.at.
> 

-- 
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 django-developers+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/D7000C61-69C0-4E59-9DB8-4BB1413B0C98%40tomforb.es.


signature.asc
Description: Message signed with OpenPGP