Re: remove_stale_contenttypes doesn't remove entries for renamed apps.

[Adam Johnson]

Mariusz makes the point on the ticket that this can cause data loss for
custom content types, which is true.

This seems to be a fairly thorny problem to me since there are several
different data loss risks. Perhaps a documentation change would be the
easiest first step - one can always remove particular stale content types
in a data migration.

On Tue, 31 Dec 2019 at 14:20, gowtham kommineni 
wrote:

> Hi Adam
>
> Please link to the ticket here.
>>
>
> ticket: https://code.djangoproject.com/ticket/31123
> PR: https://github.com/django/django/pull/12257
>
> --
> 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/e27e1fd5-9ba9-4b9d-b9a0-f477fb353769%40googlegroups.com
> 
> .
>


-- 
Adam

-- 
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/CAMyDDM0OVRURkJtq9-mXyUgzHWMdK2JxAVxrOJdsQmipuYkVyQ%40mail.gmail.com.

Re: declarative settings

[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 myself. Can
you describe in more detail?

For me, I can only imagine it would violate the "principle of least
astonishment" that if I had app A installed for some time, then installed
app B on top, app B would change the default or manually configured
settings of app A. I would prefer if app B complained (via system check)
that I had an incompatible app A configuration.

On Tue, 31 Dec 2019 at 18:10, Christian González <
christian.gonza...@nerdocs.at> wrote:

> Hi all,
>
> thanks for your fast response - it seems that this is not a "ah, forget
> it, boooring." theme.
> I'll try to answer all (for me) relevant things at once here - sorry to
> write such a huge mail.
> *@Adam Johnson:*
>
> * 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 of easily providing defaults, complex logic such as
> deriving one value from multiple settings, and being read from settings at
> runtime rather than import time.
>
> This is a good approach too, but it's not namespaced automatically. And
> app settings can't provide and override settings from other apps. 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).
>
>
> I am in favour of most libraries adding a single setting that controls
> them, like DRF has REST_FRAMEWORK. I know django-cors-headers doesn't
> implement the pattern but this is for legacy reasons since I took it over.
>
> Yes, this basically means namespacing. Depending on the size of the
> library, this could be one big bunch of a setting.
>
> I think this pattern solves your first concern Christian.
>
> No it doesn't completely. I used this pattern myself in GDAPS, copied from
> graphene (which copied from DRF). But this does _not_ solve the problem:
> This pattern  creates a per-app settings object which checks at the time of
> using (which is anywhere after main settings.py) if there is a global
> override of the local app's variable - and takes the right one. In this way
> it works. but this is not very convenient - you always have to ask the
> right settings object - it maybe would be more convenient, simpler and
> easier to code to just ask for a namespaced setting, e.g. in a dotted path
> style.
>
> like settings("django.ROOT_URLCONF") or settings("foo_app.SETTINGA")
>
> This is not a really good approach as it implements strings.
>
> As for your second concern, I think checks make manual installation of
> apps easier. If a user adds your app to INSTALLED_APPS, the system checks
> will run and can highlight any missing/misconfigured settings from
> following the installation docs. Most libraries take 3 minutes to do the
> initial install so I'm not sure of the value of automating that step
> compared to adding system checks.
>
> Perfect.
>
> *@Matthew Pava*
>
> I have worked with Drupal for a long time before Django, and am
> maintaining a few sites with Drupal, one of it rather big, with many
> domains & shared content, 40+ modules, API to ther web services, some
> modules custom coded. I learned a lot of it, but PHP is really ugly. Django
> does much better, but, compared with Drupal, it has a few drawbacks. I
> know, Drupal is a CMS, Django is a framework (which you can build a CMS
> with) - BUT: Drupal is able (like Wordpress) to add modules/plugins per web
> download and on-the-fly - it installs modules into place, has a very good
> hooks system and a plugin manager. It also was a help when I designed GDAPS
> and was one of my blueprints. Drupal however keeps ALL of it's settings in
> the database which creates many problems on it's own
> (development/deployment problems how to sync settings from disk to database
> and vice versa). I 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 automatically.
>
> But this can only be achieved by adding a line to settings.py (call the
> plugin manager), like I did:
> https://gdaps.readthedocs.io/en/latest/Installation.html#installation
>
> These are just hacks because Django doesn't have declarative settings.
> I suggest that if changing to declarative, it MUST be backwards
> compatible, yes. So there could be an _internal_ settings.py which loads
> environment variables, the bespoken config file, and like I said, **if**
> there is a settings.py in the project, Django could use it - to override
> setting

Re: remove_stale_contenttypes doesn't remove entries for renamed apps.

[Javier Buzzi]

@adam I agree with your points, about data loss, but this can still see this as 
being beneficial, perhaps the approach was just too harsh. Perhaps adding a 
flag in the management command would get everyone on board? The flag being off 
by default and only turns on if you know what you’re doing and enable it. At 
any rate i believe from what i can i see in the code it will still prompt you 
to delete the items it finds unless you added the ——no—input which prevents 
helps with data loss.

-- 
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/5c55fdaa-8d89-4baa-a08d-68b0e84c610c%40googlegroups.com.

Re: declarative settings

[Alexei Znamensky]

Hi Christian,

Definitely not a boring theme, but as pointed by others, there are many 
aspects to be taken into consideration.

Having said that, I recently stumbled on this package django-configurations 
by chance, while working on something else. It looks quite promising, as 
one can use (multiple) class inheritance to merge and combine different 
settings. As far as I can tell, it lacks the dynamic aspect of your GDAPS 
idea, so I suppose it would not solve the problem of loading plugins in 
runtime. But, for the part in which you want to load settings from 
json/yaml/toml/database/wherever, it might be simpler to piggyback on that 
project and have Configuration classes that load markup, and a config class 
that loads from DB (although this would probably be trickier than it looks).

Happy New Year to you as well, greetings from NZ
Alex

On Wednesday, January 1, 2020 at 7:11:04 AM UTC+13, Christian González 
wrote:
>
> Hi all,
>
> thanks for your fast response - it seems that this is not a "ah, forget 
> it, boooring." theme.
> I'll try to answer all (for me) relevant things at once here - sorry to 
> write such a huge mail.
> *@Adam Johnson:*
>
> * 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 of easily providing defaults, complex logic such as 
> deriving one value from multiple settings, and being read from settings at 
> runtime rather than import time.
>
> This is a good approach too, but it's not namespaced automatically. And 
> app settings can't provide and override settings from other apps. 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).
>
>
> I am in favour of most libraries adding a single setting that controls 
> them, like DRF has REST_FRAMEWORK. I know django-cors-headers doesn't 
> implement the pattern but this is for legacy reasons since I took it over.
>
> Yes, this basically means namespacing. Depending on the size of the 
> library, this could be one big bunch of a setting.
>
> I think this pattern solves your first concern Christian. 
>
> No it doesn't completely. I used this pattern myself in GDAPS, copied from 
> graphene (which copied from DRF). But this does _not_ solve the problem: 
> This pattern  creates a per-app settings object which checks at the time of 
> using (which is anywhere after main settings.py) if there is a global 
> override of the local app's variable - and takes the right one. In this way 
> it works. but this is not very convenient - you always have to ask the 
> right settings object - it maybe would be more convenient, simpler and 
> easier to code to just ask for a namespaced setting, e.g. in a dotted path 
> style.
>
> like settings("django.ROOT_URLCONF") or settings("foo_app.SETTINGA")
>
> This is not a really good approach as it implements strings.
>
> As for your second concern, I think checks make manual installation of 
> apps easier. If a user adds your app to INSTALLED_APPS, the system checks 
> will run and can highlight any missing/misconfigured settings from 
> following the installation docs. Most libraries take 3 minutes to do the 
> initial install so I'm not sure of the value of automating that step 
> compared to adding system checks.
>
> Perfect.
>
> *@Matthew Pava*
>
> I have worked with Drupal for a long time before Django, and am 
> maintaining a few sites with Drupal, one of it rather big, with many 
> domains & shared content, 40+ modules, API to ther web services, some 
> modules custom coded. I learned a lot of it, but PHP is really ugly. Django 
> does much better, but, compared with Drupal, it has a few drawbacks. I 
> know, Drupal is a CMS, Django is a framework (which you can build a CMS 
> with) - BUT: Drupal is able (like Wordpress) to add modules/plugins per web 
> download and on-the-fly - it installs modules into place, has a very good 
> hooks system and a plugin manager. It also was a help when I designed GDAPS 
> and was one of my blueprints. Drupal however keeps ALL of it's settings in 
> the database which creates many problems on it's own 
> (development/deployment problems how to sync settings from disk to database 
> and vice versa). I 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 automatically.
>
> But this can only be achieved by adding a line to settings.py (call the 
> plugin manager), like I did:
> https://gdaps.readthedocs.io/en/latest/Installation.html#installation
>
> These are just hacks because Django doesn't have declarative settings.
> I suggest that 

Django bugfix release: 3.0.2.

[Mariusz Felisiak]

Details are available on the Django project weblog:

https://www.djangoproject.com/weblog/2020/jan/02/django-bugfix-release-302/

--
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/e725922f-10ec-437f-5441-4c8c4975501b%40gmail.com.