Re: How to disable system check framework?

[Malcolm Box]

At the risk of re-opening this thread, I have just run into a very similar 
situation (see https://code.djangoproject.com/ticket/25374) and find that 
having the errors printed to the console is actually helpful - as I've had 
to silence errors to get the correct code to run, seeing if there's any 
*other* errors being "accidentally" silenced is helpful.

It seems there's actually two behaviours being conflated in 
"SILENCE_SYSTEM_CHECKS":

* Ignoring the error, so that the code will run (ie downgrade errors to 
warnings)
* Not printing the message

It's useful to be able to do the two things separately - I may want to 
downgrade an error because it's not one in my codebase, but still see if 
new instances of it creep in. Or I might want to not see any of a 
particular warning printed to the console.

Could we split this to:

IGNORED_SYSTEM_CHECKS

and 

SILENCED_SYSTEM_CHECKS


Malcolm

On Thursday, 27 August 2015 14:09:06 UTC+1, Tim Graham wrote:
>
> I created a ticket and pull request for the silencing of error/critical 
> messages:
> https://code.djangoproject.com/ticket/25318#ticket
> https://github.com/django/django/pull/5197
>
> On Tuesday, August 25, 2015 at 11:03:18 AM UTC-4, Carl Meyer wrote:
>>
>> On 08/25/2015 08:57 AM, Marcin Nowak wrote: 
>> > Well, I'm not sure now, because Tim wrote that it was a design decision 
>> > and it is well documented. 
>>
>> I still think we should change that design. It is simply wrong to have a 
>> setting called `SILENCED_SYSTEM_CHECKS` that fails to actually _silence_ 
>> the check IDs listed. 
>>
>> > Also please note that silencing specific errors is not the best 
>> solution. 
>> > In the first case E116 may be untrue and may be silenced, but for other 
>> > models this error may be true and shouldn't be silenced at all. 
>> > Silencing all E116 will give us messy information about state. 
>>
>> That's why I think in this case the best solution is to actually fix the 
>> error, not silence it; Django should be able to find a find a field even 
>> if it's monkeypatched-in, as long as the monkeypatch happens in time. 
>>
>> Carl 
>>
>>

-- 
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 post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/dc4e410c-708f-472b-bde2-49a45ad4e39d%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: How to disable system check framework?

[Marcin Nowak]

On Thursday, August 27, 2015 at 3:09:06 PM UTC+2, Tim Graham wrote:
>
> I created a ticket and pull request for the silencing of error/critical 
> messages:
> https://code.djangoproject.com/ticket/25318#ticket
> https://github.com/django/django/pull/5197
>
>>
>>
Thanks, Tim!

Marcin.
 

-- 
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 post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/9ecf68e4-35a7-483b-983e-c5ef9f9d3533%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: How to disable system check framework?

[Tim Graham]

I created a ticket and pull request for the silencing of error/critical 
messages:
https://code.djangoproject.com/ticket/25318#ticket
https://github.com/django/django/pull/5197

On Tuesday, August 25, 2015 at 11:03:18 AM UTC-4, Carl Meyer wrote:
>
> On 08/25/2015 08:57 AM, Marcin Nowak wrote: 
> > Well, I'm not sure now, because Tim wrote that it was a design decision 
> > and it is well documented. 
>
> I still think we should change that design. It is simply wrong to have a 
> setting called `SILENCED_SYSTEM_CHECKS` that fails to actually _silence_ 
> the check IDs listed. 
>
> > Also please note that silencing specific errors is not the best 
> solution. 
> > In the first case E116 may be untrue and may be silenced, but for other 
> > models this error may be true and shouldn't be silenced at all. 
> > Silencing all E116 will give us messy information about state. 
>
> That's why I think in this case the best solution is to actually fix the 
> error, not silence it; Django should be able to find a find a field even 
> if it's monkeypatched-in, as long as the monkeypatch happens in time. 
>
> Carl 
>
>

-- 
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 post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/4bd1edea-ca58-44b2-bf75-b05443f982ea%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: How to disable system check framework?

[Marcin Nowak]

On Wednesday, August 26, 2015 at 9:08:16 AM UTC+2, Florian Apolloner wrote:
>
> Ups, not enough coffee yet, the admin.ready() just registers the checks, 
> it does not execute them, so order should not matter -- I shall close my 
> browser now and get some coffee :D
>

I don't know how exactly order of ready() calls is changing. After 
switching to SimpleAdminApp the order was changed. Why? I don't know, but 
it works. 

This disables admin autodiscovery though, I doubt that is what you want… 


I have a call for admin.autodiscover() in my urls, so there is no 
difference (?). I don't see any...

BR,
Marcin

-- 
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 post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/96451ce3-e982-40b4-88e6-e2fb4f8528e9%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: How to disable system check framework?

[Florian Apolloner]

Ups, not enough coffee yet, the admin.ready() just registers the checks, it 
does not execute them, so order should not matter -- I shall close my 
browser now and get some coffee :D

On Wednesday, August 26, 2015 at 9:07:15 AM UTC+2, Florian Apolloner wrote:
>
> I think the fix for you currently is to put __your__ app before the admin 
> app, this way your ready() will patch the user first and then the admin 
> checks run.
>
> On Wednesday, August 26, 2015 at 9:06:07 AM UTC+2, Florian Apolloner wrote:
>>
>>
>>
>> On Tuesday, August 25, 2015 at 6:19:44 PM UTC+2, Marcin Nowak wrote:
>>>
>>> Thanks, Carl. This specific error can solved by changing 
>>> 'django.contrib.admin' to 'django.contrib.admin.apps.SimpleAdminConfig' in 
>>> INSTALLED_APPS.
>>>
>>
>> This disables admin autodiscovery though, I doubt that is what you want… 
>>
>

-- 
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 post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/f76d985a-6d32-4a59-b4a1-183db9d0c0cc%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: How to disable system check framework?

[Florian Apolloner]

I think the fix for you currently is to put __your__ app before the admin 
app, this way your ready() will patch the user first and then the admin 
checks run.

On Wednesday, August 26, 2015 at 9:06:07 AM UTC+2, Florian Apolloner wrote:
>
>
>
> On Tuesday, August 25, 2015 at 6:19:44 PM UTC+2, Marcin Nowak wrote:
>>
>> Thanks, Carl. This specific error can solved by changing 
>> 'django.contrib.admin' to 'django.contrib.admin.apps.SimpleAdminConfig' in 
>> INSTALLED_APPS.
>>
>
> This disables admin autodiscovery though, I doubt that is what you want… 
>

-- 
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 post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/9a01c325-ebad-44d3-8d7d-9df4e4808f0e%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: How to disable system check framework?

[Florian Apolloner]

On Tuesday, August 25, 2015 at 6:19:44 PM UTC+2, Marcin Nowak wrote:
>
> Thanks, Carl. This specific error can solved by changing 
> 'django.contrib.admin' to 'django.contrib.admin.apps.SimpleAdminConfig' in 
> INSTALLED_APPS.
>

This disables admin autodiscovery though, I doubt that is what you want… 

-- 
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 post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/a8d6a967-c311-43c6-8a81-f7c049d6d673%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: How to disable system check framework?

[Marcin Nowak]

>
>
>> I think likely the root problem here is that your monkeypatch is in a 
>> module which is not imported when validation runs. If I were you, I'd 
>> make sure that your `admin.py` imports whatever module does the 
>> monkeypatching, and then I'd expect this error to go away. 
>>
>
> Yes, Django does not "know" about patched user in a validation stage.
> I will try to change it, but this is an example only.
>  
>

Thanks, Carl. This specific error can solved by changing 
'django.contrib.admin' to 'django.contrib.admin.apps.SimpleAdminConfig' in 
INSTALLED_APPS.

BR,
Marcin

-- 
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 post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/7c0cac6d-728e-401d-93a4-20ce5ffb8e03%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: How to disable system check framework?

[Carl Meyer]

On 08/25/2015 09:15 AM, Marcin Nowak wrote:
> PS. I would like to avoid any monkey patches, hacks, and just omit
> obstacles. :)

I agree. In this case, you should use a custom User model instead of
monkey-patching User, but you asked us not to discuss that question :-)

Carl

-- 
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 post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/55DC8736.7080302%40oddbird.net.
For more options, visit https://groups.google.com/d/optout.


signature.asc
Description: OpenPGP digital signature

Re: How to disable system check framework?

[Marcin Nowak]

On Tuesday, August 25, 2015 at 4:51:51 PM UTC+2, Carl Meyer wrote:
>
>
> I think likely the root problem here is that your monkeypatch is in a 
> module which is not imported when validation runs. If I were you, I'd 
> make sure that your `admin.py` imports whatever module does the 
> monkeypatching, and then I'd expect this error to go away. 
>

Yes, Django does not "know" about patched user in a validation stage.
I will try to change it, but this is an example only.
 
PS. I would like to avoid any monkey patches, hacks, and just omit 
obstacles. :)
Django is a good (the best?) web framework for rapid development, but 
sometimes is a part of a bigger stack. 
In that case some unnecessary Django`s limitations/forcings may be 
problematic to maintain whole projects.   

BR,
Marcin

-- 
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 post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/94d8fbf8-7e0e-49d5-81e4-2d1372ac3fca%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: How to disable system check framework?

[Carl Meyer]

Hi Ma

On 08/25/2015 07:46 AM, Marcin Nowak wrote:
> Thanks for replies, Carl, Adam, Shai.
> 
> But I think you're worrying too much for too many things. You're
> trying to control everything, trying to replace automated tests with
> system check framework, trying to block "invalid" operations, etc,
> etc. This is bad way, IMO.
> 
> Let's see a small example how system check framework works:
> 
> 1. I'm adding custom field to user (by patching User models, don't
> ask why - other ways does not work)
> 
> class MyAppConfig(AppConfig): name = 'my app'
> 
> def ready(self): from django.contrib.auth.models import User from
> django.db import models
> 
> User.add_to_class('is_verified', models.BooleanField(default=False))
> 
> 2. I'm adding new field to admin interface
> 
> @admin.register(User) class MyUserAdmin(UserAdmin): [...] list_filter
> = ('is_superuser', 'is_active', 'is_verified') [...]
> 
> 3. Django raises an error:
> 
> ERRORS: : (admin.E116) The value of 
> 'list_filter[2]' refers to 'is_verified', which does not refer to a
> Field.
> 
> Which is not true!

I think likely the root problem here is that your monkeypatch is in a
module which is not imported when validation runs. If I were you, I'd
make sure that your `admin.py` imports whatever module does the
monkeypatching, and then I'd expect this error to go away.

> 4. I'm silencing E116:
> 
> SILENCED_SYSTEM_CHECKS = ['admin.E116']
> 
> 5. Django starts, admin works  (and new filter works also), but 
> runserver still prints out a false message:
> 
> Performing system checks...
> 
> System check identified some issues:
> 
> ERRORS: : (admin.E116) The value of 
> 'list_filter[2]' refers to 'is_verified', which does not refer to a
> Field.
> 
> I know that this is unbelievable, Carl, but the message *is
> displayed!* And prints out untrue message at all...

Yes, I guess it is by design that errors (as opposed to warnings) are
still printed even if "silenced". I didn't realize that - I guess I've
never tried to silence a system check error, just warnings.

That seems like a bad design decision to me, and I think we should
change it. Silenced should mean silenced.

Carl

-- 
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 post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/55DC80F7.50407%40oddbird.net.
For more options, visit https://groups.google.com/d/optout.


signature.asc
Description: OpenPGP digital signature

Re: How to disable system check framework?

[Carl Meyer]

On 08/25/2015 08:57 AM, Marcin Nowak wrote:
> Well, I'm not sure now, because Tim wrote that it was a design decision
> and it is well documented.

I still think we should change that design. It is simply wrong to have a
setting called `SILENCED_SYSTEM_CHECKS` that fails to actually _silence_
the check IDs listed.

> Also please note that silencing specific errors is not the best solution. 
> In the first case E116 may be untrue and may be silenced, but for other
> models this error may be true and shouldn't be silenced at all.
> Silencing all E116 will give us messy information about state.

That's why I think in this case the best solution is to actually fix the
error, not silence it; Django should be able to find a find a field even
if it's monkeypatched-in, as long as the monkeypatch happens in time.

Carl

-- 
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 post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/55DC83A8.8050907%40oddbird.net.
For more options, visit https://groups.google.com/d/optout.


signature.asc
Description: OpenPGP digital signature

Re: How to disable system check framework?

[Marcin Nowak]

On Tuesday, August 25, 2015 at 3:59:20 PM UTC+2, Aymeric Augustin wrote:
>
>
> There’s an obvious bug here: silenced checks are still printed out — even 
> though they don’t prevent Django from starting.
> I hadn’t understood that from your earlier messages. It shouldn’t be very 
> hard to fix.
>
>
Don't worry, it may come from my poor english skills.
 

> If you want to make sure we don’t lose track of this bug, you should file 
> a ticket.
>
>
Well, I'm not sure now, because Tim wrote that it was a design decision and 
it is well documented.
I would like to turn off system checker, live without it, and rely on my 
automated tests only. This should be simplest solution for uncommon cases, 
and should be simple to implement without design change.

Also please note that silencing specific errors is not the best solution. 
In the first case E116 may be untrue and may be silenced, but for other 
models this error may be true and shouldn't be silenced at all.
Silencing all E116 will give us messy information about state.


BR,
Marcin

-- 
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 post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/7c9a3567-ba85-4184-83ac-3bd6e9a99b69%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: How to disable system check framework?

[Tim Graham]

It seems this was an intentional design decision as the documentation 
states, "Silenced warnings will no longer be output to the console; 
silenced errors will still be printed, but will not prevent management 
commands from running." I guess it could/should be revisited?

https://docs.djangoproject.com/en/1.8/ref/settings/#silenced-system-checks

On Tuesday, August 25, 2015 at 9:59:20 AM UTC-4, Aymeric Augustin wrote:
>
> Hello Marcin,
>
> There’s an obvious bug here: silenced checks are still printed out — even 
> though they don’t prevent Django from starting.
>
> I hadn’t understood that from your earlier messages. It shouldn’t be very 
> hard to fix.
>
> If you want to make sure we don’t lose track of this bug, you should file 
> a ticket.
>
> -- 
> Aymeric.
>
>
>
> On 25 août 2015, at 15:46, Marcin Nowak  > wrote:
>
> Thanks for replies, Carl, Adam, Shai.
>
> But I think you're worrying too much for too many things. You're trying to 
> control everything, trying to replace automated tests with system check 
> framework, trying to block "invalid" operations, etc, etc. This is bad way, 
> IMO.
>  
> Let's see a small example how system check framework works:
>
> 1. I'm adding custom field to user (by patching User models, don't ask why 
> - other ways does not work)
>
> class MyAppConfig(AppConfig):
> name = 'my app'
>
> def ready(self):
> from django.contrib.auth.models import User
> from django.db import models
>
> User.add_to_class('is_verified', 
> models.BooleanField(default=False))
>
> 2. I'm adding new field to admin interface
>
> @admin.register(User)
> class MyUserAdmin(UserAdmin):
> [...]
> list_filter = ('is_superuser', 'is_active', 'is_verified')
> [...]
>
> 3. Django raises an error:
>
> ERRORS:
> : (admin.E116) The value of 
> 'list_filter[2]' refers to 'is_verified', which does not refer to a Field.
>
> Which is not true!
>
> 4. I'm silencing E116:
>
> SILENCED_SYSTEM_CHECKS = ['admin.E116']
>
> 5. Django starts, admin works  (and new filter works also), but runserver 
> still prints out a false message:
>
> Performing system checks...
>
> System check identified some issues:
>
> ERRORS:
> : (admin.E116) The value of 
> 'list_filter[2]' refers to 'is_verified', which does not refer to a Field.
>
> I know that this is unbelievable, Carl, but the message *is displayed!*
> And prints out untrue message at all...
>
> Sorry, but this is not helpful...
>
> BR,
> Marcin
>
> -- 
> 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-develop...@googlegroups.com .
> To post to this group, send email to django-d...@googlegroups.com 
> .
> Visit this group at http://groups.google.com/group/django-developers.
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/django-developers/7fef0c25-2706-4072-86d9-ca3e0dbc03c6%40googlegroups.com
>  
> <https://groups.google.com/d/msgid/django-developers/7fef0c25-2706-4072-86d9-ca3e0dbc03c6%40googlegroups.com?utm_medium=email&utm_source=footer>
> .
> For more options, visit https://groups.google.com/d/optout.
>
>
>

-- 
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 post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/99f6896f-00d7-414a-b1c2-74d1e359607e%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: How to disable system check framework?

[Aymeric Augustin]

Hello Marcin,

There’s an obvious bug here: silenced checks are still printed out — even 
though they don’t prevent Django from starting.

I hadn’t understood that from your earlier messages. It shouldn’t be very hard 
to fix.

If you want to make sure we don’t lose track of this bug, you should file a 
ticket.

-- 
Aymeric.



> On 25 août 2015, at 15:46, Marcin Nowak  wrote:
> 
> Thanks for replies, Carl, Adam, Shai.
> 
> But I think you're worrying too much for too many things. You're trying to 
> control everything, trying to replace automated tests with system check 
> framework, trying to block "invalid" operations, etc, etc. This is bad way, 
> IMO.
>  
> Let's see a small example how system check framework works:
> 
> 1. I'm adding custom field to user (by patching User models, don't ask why - 
> other ways does not work)
> 
> class MyAppConfig(AppConfig):
> name = 'my app'
> 
> def ready(self):
> from django.contrib.auth.models import User
> from django.db import models
> 
> User.add_to_class('is_verified', models.BooleanField(default=False))
> 
> 2. I'm adding new field to admin interface
> 
> @admin.register(User)
> class MyUserAdmin(UserAdmin):
> [...]
> list_filter = ('is_superuser', 'is_active', 'is_verified')
> [...]
> 
> 3. Django raises an error:
> 
> ERRORS:
> : (admin.E116) The value of 'list_filter[2]' 
> refers to 'is_verified', which does not refer to a Field.
> 
> Which is not true!
> 
> 4. I'm silencing E116:
> 
> SILENCED_SYSTEM_CHECKS = ['admin.E116']
> 
> 5. Django starts, admin works  (and new filter works also), but runserver 
> still prints out a false message:
> 
> Performing system checks...
> 
> System check identified some issues:
> 
> ERRORS:
> : (admin.E116) The value of 'list_filter[2]' 
> refers to 'is_verified', which does not refer to a Field.
> 
> I know that this is unbelievable, Carl, but the message is displayed!
> And prints out untrue message at all...
> 
> Sorry, but this is not helpful...
> 
> BR,
> Marcin
> 
> -- 
> 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 
> <mailto:django-developers+unsubscr...@googlegroups.com>.
> To post to this group, send email to django-developers@googlegroups.com 
> <mailto:django-developers@googlegroups.com>.
> Visit this group at http://groups.google.com/group/django-developers 
> <http://groups.google.com/group/django-developers>.
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/django-developers/7fef0c25-2706-4072-86d9-ca3e0dbc03c6%40googlegroups.com
>  
> <https://groups.google.com/d/msgid/django-developers/7fef0c25-2706-4072-86d9-ca3e0dbc03c6%40googlegroups.com?utm_medium=email&utm_source=footer>.
> For more options, visit https://groups.google.com/d/optout 
> <https://groups.google.com/d/optout>.

-- 
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 post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/8D382E82-7AF2-4FD4-B4DC-79101D75E9DE%40polytechnique.org.
For more options, visit https://groups.google.com/d/optout.

Re: How to disable system check framework?

[Marcin Nowak]

Thanks for replies, Carl, Adam, Shai.

But I think you're worrying too much for too many things. You're trying to 
control everything, trying to replace automated tests with system check 
framework, trying to block "invalid" operations, etc, etc. This is bad way, 
IMO.
 
Let's see a small example how system check framework works:

1. I'm adding custom field to user (by patching User models, don't ask why 
- other ways does not work)

class MyAppConfig(AppConfig):
name = 'my app'

def ready(self):
from django.contrib.auth.models import User
from django.db import models

User.add_to_class('is_verified', models.BooleanField(default=False))

2. I'm adding new field to admin interface

@admin.register(User)
class MyUserAdmin(UserAdmin):
[...]
list_filter = ('is_superuser', 'is_active', 'is_verified')
[...]

3. Django raises an error:

ERRORS:
: (admin.E116) The value of 
'list_filter[2]' refers to 'is_verified', which does not refer to a Field.

Which is not true!

4. I'm silencing E116:

SILENCED_SYSTEM_CHECKS = ['admin.E116']

5. Django starts, admin works  (and new filter works also), but runserver 
still prints out a false message:

Performing system checks...

System check identified some issues:

ERRORS:
: (admin.E116) The value of 
'list_filter[2]' refers to 'is_verified', which does not refer to a Field.

I know that this is unbelievable, Carl, but the message *is displayed!*
And prints out untrue message at all...

Sorry, but this is not helpful...

BR,
Marcin

-- 
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 post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/7fef0c25-2706-4072-86d9-ca3e0dbc03c6%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: How to disable system check framework?

[Adam Johnson]

Marcin - you can "tidy up" some monkey patches, or at least make them 
robust to the code you're replacing changing, by 
using https://github.com/adamchainz/patchy .

I'm -1 - we've recently been implementing project system checks for our 
team and they are super useful. We even have one that checks if 
requirements.txt has been updated since the virtual environment was 
created. It would be bothersome if there was a way for developers to 
disable *all* checks for themselves. Also whilst many 3rd-party apps are 
adding checks recently, you don't want to miss out on the help they provide.

On Wednesday, August 12, 2015 at 6:35:34 PM UTC+1, Shai Berger wrote:
>
> Hi all, 
>
> On Tuesday 11 August 2015 19:05:26 Carl Meyer wrote: 
> > On 08/11/2015 10:44 AM, Marcin Nowak wrote: 
> > > I need to list ALL errors and warnings, which is: 
> > >   * unhandy and it would require maintain a big list (especially after 
> > > upgrading Django to newer version) 
> > 
> > That's a good reason not to include this "feature." How can you say now 
> > that a check included in a future Django version won't be relevant to 
> > you or catch a bug in your code, when you don't even know yet what that 
> > check is? 
> > 
>
> Further -- the cheks framework allows your apps or 3rd-party apps to add 
> checks of their own. So, the above argument also multiplies to all future 
> versions of all apps you use. 
>
> > 
> > All that said, [...] I think users who don't understand how 
> > SILENCED_SYSTEM_CHECKS works may be tempted to use it to "just make the 
> > errors go away", but all in all I'm still only -0.5. 
> > 
>
> FWIW, I'm -1. 
>
> I could be supportive of a --without-system-checks flag, which I can see 
> useful 
> during development ("I know there's a problem here, I want to solve 
> something 
> else first"). This would imply that a user needs to decide, every run 
> anew, 
> that they don't want the checks. I'm aware that a user like Marcin could 
> just 
> use an alias, or change their manage.py, to have the flag included 
> automatically; I'd take a "consenting adults" approach towards that sort 
> of 
> abuse. 
>
> Shai. 
>

-- 
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 post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/fa7b4deb-b373-4363-8264-9288ba15085a%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: How to disable system check framework?

[Shai Berger]

Hi all,

On Tuesday 11 August 2015 19:05:26 Carl Meyer wrote:
> On 08/11/2015 10:44 AM, Marcin Nowak wrote:
> > I need to list ALL errors and warnings, which is:
> >   * unhandy and it would require maintain a big list (especially after
> > upgrading Django to newer version)
> 
> That's a good reason not to include this "feature." How can you say now
> that a check included in a future Django version won't be relevant to
> you or catch a bug in your code, when you don't even know yet what that
> check is?
> 

Further -- the cheks framework allows your apps or 3rd-party apps to add 
checks of their own. So, the above argument also multiplies to all future 
versions of all apps you use.

> 
> All that said, [...] I think users who don't understand how
> SILENCED_SYSTEM_CHECKS works may be tempted to use it to "just make the
> errors go away", but all in all I'm still only -0.5.
> 

FWIW, I'm -1.

I could be supportive of a --without-system-checks flag, which I can see useful 
during development ("I know there's a problem here, I want to solve something 
else first"). This would imply that a user needs to decide, every run anew, 
that they don't want the checks. I'm aware that a user like Marcin could just 
use an alias, or change their manage.py, to have the flag included 
automatically; I'd take a "consenting adults" approach towards that sort of 
abuse.

Shai.

Re: How to disable system check framework?

[Carl Meyer]

Hi Marcin,

On 08/11/2015 10:44 AM, Marcin Nowak wrote:
> They aren't really silenced, but skipped. I would like to silence them
> for real. They are skipped, but still printed out.

I'm not sure what you're referring to here. If you include a system
check warning code in the SILENCED_SYSTEM_CHECKS setting, as far as I'm
aware that warning is completely silenced, and is not printed anywhere.
If you think otherwise, you'll need to provide a specific example.

> Let's assume that I am a guy who wants to silence every system check.

We can assume that, but it doesn't provide an argument for anything
unless you can make a reasonable case for _why_ you want to do that, and
some evidence that other people also may want to do the same thing
(these two are connected). So far I don't see either.

> I
> need to list ALL errors and warnings, which is:
>   * unhandy and it would require maintain a big list (especially after
> upgrading Django to newer version)

That's a good reason not to include this "feature." How can you say now
that a check included in a future Django version won't be relevant to
you or catch a bug in your code, when you don't even know yet what that
check is?

We don't add checks just for the fun of it -- we add them when we have
good evidence that something is likely to be an error in many people's
codebases. Such checks should be silenced when you understand the
specific error and understand why it's not relevant in your unusual
case. There's no way that you can make such an assertion about all
possible future checks.

>   * messages are still visible (I don't need them and I don't want to
> read them, and any other developer don't want to read them)

I don't think this is true.

>   * django bootstraping is still slower due to executing system checks.

This isn't relevant unless you have profiling data showing a noticeable
difference in a realistic use case.

> As an old-and-experienced-guy I want to disable (completely) system
> checks on my responsibility. 
> Just belive me - I know what I'm doing. And I don't want to hack Django
> to do any non-typical things.  

Why not? Isn't "I've hacked Django to do lots of non-typical things" the
basis of your desire to disable system checks? So what's wrong with one
more?

> Why you can't add just one setting to bypass something which is
> currently built-in? Is that a really big problem?

Because every new setting is a new conditional path that has to be
tested, and the interaction of every other feature with that new
conditional path is now in theory a possible bug location. In other
words, a single new boolean setting doubles the total number of possible
configurations of Django that might contain a bug and need testing.

All new code is a maintenance burden, and requires stronger
justification than "one person said they wanted it."

All that said, if we do this, it should be spelled
`SILENCED_SYSTEM_CHECKS = ['*']`. I don't think there is ever a good
case for using it, and I think users who don't understand how
SILENCED_SYSTEM_CHECKS works may be tempted to use it to "just make the
errors go away", but all in all I'm still only -0.5.

Carl

-- 
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 post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/55CA1D46.10606%40oddbird.net.
For more options, visit https://groups.google.com/d/optout.


signature.asc
Description: OpenPGP digital signature

Re: How to disable system check framework?

[Marcin Nowak]

Tim,

They aren't really silenced, but skipped. I would like to silence them for 
real. They are skipped, but still printed out.

Let's assume that I am a guy who wants to silence every system check. I 
need to list ALL errors and warnings, which is:
  * unhandy and it would require maintain a big list (especially after 
upgrading Django to newer version)
  * messages are still visible (I don't need them and I don't want to read 
them, and any other developer don't want to read them)
  * django bootstraping is still slower due to executing system checks.

As an old-and-experienced-guy I want to disable (completely) system checks 
on my responsibility. 
Just belive me - I know what I'm doing. And I don't want to hack Django to 
do any non-typical things.  

Why you can't add just one setting to bypass something which is currently 
built-in? Is that a really big problem?


On Friday, August 7, 2015 at 2:32:08 PM UTC+2, Tim Graham wrote:
>
> Could you elaborate on why disabling system checks entirely is better than 
> selectively disabling checks that are problematic for you? Is it really 
> never helpful? If there are more people clamoring for this feature, I think 
> I'd be more open to it.
>
> SILENCED_SYSTEM_CHECKS = ['admin.E108', 'admin.E304', 'fields.E305', 
> 'admin.E116', 'fields.E306', 'fields.W342', 'fields'W340']
>
> On Friday, August 7, 2015 at 4:35:37 AM UTC-4, Marcin Nowak wrote:
>>
>>
>>
>> On Thursday, August 6, 2015 at 5:36:09 PM UTC+2, Tim Graham wrote:
>>>
>>> Perhaps your monkeypatches should be moved to `AppConfig.ready()` 
>>> methods so they are applied before the system check framework is invoked? 
>>>
>>
>> I'll try that, thanks. To be honest I should remove monkeypatching, I 
>> don't like it, but I don't want do it now.
>>  
>>
>>>  
>>>
>> How many problematic checks are you running into?
>>>
>>
>> Above 60 overall.
>>
>> Can you describe them a bit more? If anything, SILENCED_SYSTEM_CHECKS = 
>>> ['*'] to disable checks seems like the best option that Josh proposed, but 
>>> I'd like more justification before we spend time doing that.
>>>
>>
>> E108, E304, E305, E116, E306, many W342, W340.
>> I'm using many mappings for read-only and they don't need to be valid as 
>> regular models.
>>
>> Cheers,
>> Marcin
>>
>

-- 
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 post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/558031ee-4ebd-4e39-89c6-4ddf84b0ea04%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: How to disable system check framework?

[Tim Graham]

Could you elaborate on why disabling system checks entirely is better than 
selectively disabling checks that are problematic for you? Is it really 
never helpful? If there are more people clamoring for this feature, I think 
I'd be more open to it.

SILENCED_SYSTEM_CHECKS = ['admin.E108', 'admin.E304', 'fields.E305', 
'admin.E116', 'fields.E306', 'fields.W342', 'fields'W340']

On Friday, August 7, 2015 at 4:35:37 AM UTC-4, Marcin Nowak wrote:
>
>
>
> On Thursday, August 6, 2015 at 5:36:09 PM UTC+2, Tim Graham wrote:
>>
>> Perhaps your monkeypatches should be moved to `AppConfig.ready()` methods 
>> so they are applied before the system check framework is invoked? 
>>
>
> I'll try that, thanks. To be honest I should remove monkeypatching, I 
> don't like it, but I don't want do it now.
>  
>
>>  
>>
> How many problematic checks are you running into?
>>
>
> Above 60 overall.
>
> Can you describe them a bit more? If anything, SILENCED_SYSTEM_CHECKS = 
>> ['*'] to disable checks seems like the best option that Josh proposed, but 
>> I'd like more justification before we spend time doing that.
>>
>
> E108, E304, E305, E116, E306, many W342, W340.
> I'm using many mappings for read-only and they don't need to be valid as 
> regular models.
>
> Cheers,
> Marcin
>

-- 
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 post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/44b83a34-d414-4e28-b8e9-ac4eae2343c7%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: How to disable system check framework?

[Marcin Nowak]

Thanks for the snippet, Aymeric! I've found similar on Gist, but yours 
seems to be better. Thanks.

Marcin

On Wednesday, August 5, 2015 at 11:10:25 PM UTC+2, Aymeric Augustin wrote:
>
> Hi Marcin,
>
> Thanks for the clarification, that's helpful.
>
> The backwards compatibility wrapper looks like this in this case:
>
> @contextlib.contextmanager
> def commit_manually(using=None):
> transaction.set_autocommit(False, using)
> try:
> yield
> finally:
> transaction.set_autocommit(True, using)
>
> (typed on a phone and not tested)
>
> We recently decided against shipping compatibility wrappers with Django 
> because the interaction with the deprecation policy is messy. However, like 
> Tim said, we're trying to make it easier to have such wrappers.
>
> -- 
> Aymeric.
>
> Le 5 août 2015 à 15:59, Marcin Nowak > 
> a écrit :
>
> Hi Aymeric,
>
> This project is complex, as I said before, and works well with Django 1.4. 
> But we need to upgrade it to newer version because of lack of support, 
> security issues, and simplifcation of maintenance and growth (we're 
> currently using three different Django versions, from 1.4 to 1.7, and we've 
> decided to upgrade all subprojects to 1.8)
>
> commit_manually() is used within long-live processes running as a mgmt 
> commands, where is used multiprocessing too.
> Whole process is complicated and hard to maintain. I would like to avoid 
> logical / flow changes, whose are required to replace commit_manually() 
> with atomic().
> Second use case is a extract-transform-load subsytem, which also requires 
> precise development of queries, commits and rollbacks. I'm afraid that 
> upgrade of it may be also hard.
>
> I think that there are rare cases, when manual transaction handling is 
> required and should be available for punctilious developer.
> *BUT* I can't say that atomic() does not fit my needs. I know how it work 
> (I belive), but it may not cover current cases (implementation).
>
> I must try to do replacement or bring old behaviour of commit_manually() 
> with my custom wrapper. I'm trying to change code as less as possible.
>
> You're asking what could be done better.. Generally speaking - an API 
> compatibility layer. As a maintainer of big and old project I would like to 
> import "commit_manually" from special module delivered with Django, which 
> will guarantee stability and compatibility. This may be even undocumented. 
> Manual commit() and rollback() functions are provided in transaction module 
> (thanks so much for that!), so making compat layer should be possible, I 
> think.
>
> Kind Regards,
> Marcin
>
> On Wednesday, August 5, 2015 at 1:16:38 PM UTC+2, Aymeric Augustin wrote:
>>
>> On 5 août 2015, at 11:09, Marcin Nowak  wrote: 
>>
>> > I'm using commit_manually() frequently, but this decorator was 
>> removed... 
>>
>> Hi Marcin, 
>>
>> Sorry for derailing the discussion a bit, but could you clarify why you 
>> were 
>> using this API? I removed it after failing to find a use case where it 
>> would 
>> be preferrable to commit_on_success(). I’d love to know if I missed 
>> something 
>> in order to avoid making similar mistakes again. 
>>
>> Using commit_manually() properly required great care -- and a try/finally 
>> construct in practice -- to ensure that no code path escaped without a 
>> commit 
>> or a rollback. It also required a massive amount of boilerplate to avoid 
>> masking exceptions: 
>>
>> - 
>> https://groups.google.com/d/msg/django-developers/S3a5UAqAsmg/7C27UGl6G_0J 
>> - https://code.djangoproject.com/ticket/6623 
>>
>> If you replace it with transaction.atomic() and remove the boilerplate, 
>> you 
>> get the same behavior with ten times less code. 
>>
>> In case removing the boilerplate creates too much code churn, I 
>> documented a 
>> real drop-in replacement that doesn't have the drawbacks of 
>> commit_manually: 
>> https://docs.djangoproject.com/en/1.6/topics/db/transactions/#id5 
>>
>> What could I have done better? 
>>
>> If you don't want any changes in Django -- your posts to this list are 
>> often 
>> after-the-fact complains about new features -- perhaps you could stick 
>> with 
>> whatever version of Django you're currently running? 
>>
>> -- 
>> Aymeric. 
>>
>>
>>
>>
>> -- 
> 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-develop...@googlegroups.com .
> To post to this group, send email to django-d...@googlegroups.com 
> .
> Visit this group at http://groups.google.com/group/django-developers.
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/django-developers/3257c139-f52e-422f-8eb4-5a97771ca367%40googlegroups.com
>  
> 
> .
> F

Re: How to disable system check framework?

[Marcin Nowak]

On Thursday, August 6, 2015 at 5:36:09 PM UTC+2, Tim Graham wrote:
>
> Perhaps your monkeypatches should be moved to `AppConfig.ready()` methods 
> so they are applied before the system check framework is invoked? 
>

I'll try that, thanks. To be honest I should remove monkeypatching, I don't 
like it, but I don't want do it now.
 

>  
>
How many problematic checks are you running into?
>

Above 60 overall.

Can you describe them a bit more? If anything, SILENCED_SYSTEM_CHECKS = 
> ['*'] to disable checks seems like the best option that Josh proposed, but 
> I'd like more justification before we spend time doing that.
>

E108, E304, E305, E116, E306, many W342, W340.
I'm using many mappings for read-only and they don't need to be valid as 
regular models.

Cheers,
Marcin

-- 
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 post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/f85884dc-8c08-4d04-a0fd-f55e0329c8e6%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: How to disable system check framework?

[Tim Graham]

Perhaps your monkeypatches should be moved to `AppConfig.ready()` methods 
so they are applied before the system check framework is invoked? Model and 
admin validation were part of Django 1.4 too, by the way.

How many problematic checks are you running into? Can you describe them a 
bit more? If anything, SILENCED_SYSTEM_CHECKS = ['*'] to disable checks 
seems like the best option that Josh proposed, but I'd like more 
justification before we spend time doing that.

Does anyone else have a desire to completely disable system checks?

On Wednesday, August 5, 2015 at 5:09:07 AM UTC-4, Marcin Nowak wrote:
>
> Thank, Josh.
>
> I'm upgrading mature and complex project, which have some tricky parts 
> implemented like a monkey-patched user model, which is applied after system 
> chceck execution. So Django complains about missing fields in ModelAdmin, 
> but patch works fine. There were some complains about doubled mappings to 
> fields, but I've removed them. Generally speaking I don't need System 
> Check, because I can find soultion myself other way.
>
> Migrations are similar - they are too simple/limited for my needs. They 
> operate on models, but I'm working mainly with database and I'm creating 
> mappings for tables and views for easy querying. So I don't need builtin 
> migrations feature.
>
> I'm using commit_manually() frequently, but this decorator was removed... 
>
> And so on...
>
> That's why I feel that working with Django is harder. It's more strict, 
> useful tools/helpers are missing, there is more features which should be 
> bypassed/omitted. I feel that is harder to do simple things... Or maybe I'm 
> getting old. ;)
>
> Cheers,
> Marcin
>
>
> On Wednesday, August 5, 2015 at 3:08:26 AM UTC+2, Josh Smeaton wrote:
>>
>> Your "scare quotes" for "feature" are really disappointing. Especially 
>> considering that the checks were hardcoded and couldn't be silenced prior 
>> to the "system check framework".
>>
>> > Working with Django is getting harder with every new version.
>>
>> If you want to turn off new features or extension points, then I'd 
>> imagine there'd be more work than for the regular user. Otherwise, I 
>> couldn't disagree more.
>>
>> Anyhow, you want to turn off system checks for some reason. Here are some 
>> potential ways forward:
>>
>> - Target the checks that are incorrectly spitting out errors or warnings, 
>> and fix those.
>> - Provide another setting "DISABLE_CHECKS" or something similar that will 
>> prevent checks running altogether (probably not ideal, new settings are 
>> hard to get into core, especially when the benefit here is still 
>> questionable).
>> - Provide a special value for the existing SILENCED_SYSTEM_CHECKS setting 
>> that causes all checks to be silenced.
>>
>> You haven't really said much about the issue other than it bothers you. 
>> The main purpose of checks are for development - so it doesn't have any 
>> runtime or deployment time penalties. Perhaps if you took some time to 
>> justify why users other than yourself might want to disable the check 
>> framework, it'd be easier to start looking at solutions to problems.
>>
>> Cheers
>>
>>
>> On Wednesday, 5 August 2015 01:16:21 UTC+10, Marcin Nowak wrote:
>>>
>>> Thanks, Carl. I know about silencing but I want to disable unwanted 
>>> "feature". Working with Django is getting harder with every new version. 
>>>
>>>
>>> On Tuesday, August 4, 2015 at 3:25:22 PM UTC+2, Carl Meyer wrote:
>>>>
>>>>
>>>> > On Aug 4, 2015, at 9:18 AM, Marcin Nowak  
>>>> wrote: 
>>>> > 
>>>> > I need to upgrade project to Django 1.8 but the SystemCheck Framework 
>>>> bothers me. 
>>>> > It complains about thigs that should work, even if they are a little 
>>>> tricky. 
>>>> > 
>>>> > I need to disable system checks designed for blogs and other simple 
>>>> sites. How can I do that? 
>>>>
>>>> The third paragraph of the system checks documentation [1] links to 
>>>> [2]. 
>>>>
>>>> Also, this is a question about using Django, not developing Django, so 
>>>> it belongs on the django-users mailing list, not here. 
>>>>
>>>> Carl 
>>>>
>>>> [1] https://docs.djangoproject.com/en/1.8/topics/checks/ 
>>>> [2] 
>>>> https://docs.djangoproject.com/en/1.8/ref/settings/#std:setting-SILENCED_SYSTEM_CHECKS
>>>
>>>

-- 
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 post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/4d5608dd-de84-476d-8934-bd59cb0fad66%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: How to disable system check framework?

[Aymeric Augustin]

Hi Marcin,

Thanks for the clarification, that's helpful.

The backwards compatibility wrapper looks like this in this case:

@contextlib.contextmanager
def commit_manually(using=None):
transaction.set_autocommit(False, using)
try:
yield
finally:
transaction.set_autocommit(True, using)

(typed on a phone and not tested)

We recently decided against shipping compatibility wrappers with Django because 
the interaction with the deprecation policy is messy. However, like Tim said, 
we're trying to make it easier to have such wrappers.

-- 
Aymeric.

> Le 5 août 2015 à 15:59, Marcin Nowak  a écrit :
> 
> Hi Aymeric,
> 
> This project is complex, as I said before, and works well with Django 1.4. 
> But we need to upgrade it to newer version because of lack of support, 
> security issues, and simplifcation of maintenance and growth (we're currently 
> using three different Django versions, from 1.4 to 1.7, and we've decided to 
> upgrade all subprojects to 1.8)
> 
> commit_manually() is used within long-live processes running as a mgmt 
> commands, where is used multiprocessing too.
> Whole process is complicated and hard to maintain. I would like to avoid 
> logical / flow changes, whose are required to replace commit_manually() with 
> atomic().
> Second use case is a extract-transform-load subsytem, which also requires 
> precise development of queries, commits and rollbacks. I'm afraid that 
> upgrade of it may be also hard.
> 
> I think that there are rare cases, when manual transaction handling is 
> required and should be available for punctilious developer.
> BUT I can't say that atomic() does not fit my needs. I know how it work (I 
> belive), but it may not cover current cases (implementation).
> 
> I must try to do replacement or bring old behaviour of commit_manually() with 
> my custom wrapper. I'm trying to change code as less as possible.
> 
> You're asking what could be done better.. Generally speaking - an API 
> compatibility layer. As a maintainer of big and old project I would like to 
> import "commit_manually" from special module delivered with Django, which 
> will guarantee stability and compatibility. This may be even undocumented. 
> Manual commit() and rollback() functions are provided in transaction module 
> (thanks so much for that!), so making compat layer should be possible, I 
> think.
> 
> Kind Regards,
> Marcin
> 
>> On Wednesday, August 5, 2015 at 1:16:38 PM UTC+2, Aymeric Augustin wrote:
>> On 5 août 2015, at 11:09, Marcin Nowak  wrote: 
>> 
>> > I'm using commit_manually() frequently, but this decorator was removed... 
>> 
>> Hi Marcin, 
>> 
>> Sorry for derailing the discussion a bit, but could you clarify why you were 
>> using this API? I removed it after failing to find a use case where it would 
>> be preferrable to commit_on_success(). I’d love to know if I missed 
>> something 
>> in order to avoid making similar mistakes again. 
>> 
>> Using commit_manually() properly required great care -- and a try/finally 
>> construct in practice -- to ensure that no code path escaped without a 
>> commit 
>> or a rollback. It also required a massive amount of boilerplate to avoid 
>> masking exceptions: 
>> 
>> - https://groups.google.com/d/msg/django-developers/S3a5UAqAsmg/7C27UGl6G_0J 
>> - https://code.djangoproject.com/ticket/6623 
>> 
>> If you replace it with transaction.atomic() and remove the boilerplate, you 
>> get the same behavior with ten times less code. 
>> 
>> In case removing the boilerplate creates too much code churn, I documented a 
>> real drop-in replacement that doesn't have the drawbacks of commit_manually: 
>> https://docs.djangoproject.com/en/1.6/topics/db/transactions/#id5 
>> 
>> What could I have done better? 
>> 
>> If you don't want any changes in Django -- your posts to this list are often 
>> after-the-fact complains about new features -- perhaps you could stick with 
>> whatever version of Django you're currently running? 
>> 
>> -- 
>> Aymeric.
> 
> -- 
> 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 post to this group, send email to django-developers@googlegroups.com.
> Visit this group at http://groups.google.com/group/django-developers.
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/django-developers/3257c139-f52e-422f-8eb4-5a97771ca367%40googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.

-- 
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 post to this group, send email to django-developers@googlegroups.com

Re: How to disable system check framework?

[Tim Graham]

If you have a big need to use old APIs, feel free to implement them in your 
own package or even in a reusable app so that others can benefit too. There 
have been other efforts like https://github.com/arteria/django-compat to do 
so. We can't maintain them forever, lest Django become bloated and 
difficult to maintain.

If you followed the discussion about the new deprecation policy, you'll 
know that we are trying to make it easier to upgrade from one LTS to the 
next, but some things are inevitably going to change or be removed in an 
effort to improve Django. You can help us by testing preleases and giving 
feedback before final releases.

On Wednesday, August 5, 2015 at 12:49:15 PM UTC-4, Marcin Nowak wrote:
>
> No, there is not problem in this code only, but yeah - it is a big 
> problem. Real problem is that newer versions of Django are pushing 
> developers to do things by the only one way, which is good for blogs or 
> cms, or maybe new and small projects. As the result it is getting harder to 
> maintain complex project based on Django unless you stay with 
> old-and-unsupported version. And I'm not talking about atomic(), which is 
> good and simple.
>
> > And defer upgrading to a proper transaction management for another few 
> years?
>
> No. Just provide old-style wrappers (at the python-level api 
> compatibility) for old guys maintaining old projects ;)
>
> I can say something similar about generics views based on CBV - function 
> based wrappers can be built top of CBV and can be provided in django.compat 
> or django.legacy package. Just suggesting.
>  
> Cheers,
> Marcin
>
> On Wednesday, August 5, 2015 at 5:28:39 PM UTC+2, Florian Apolloner wrote:
>>
>> On Wednesday, August 5, 2015 at 3:59:39 PM UTC+2, Marcin Nowak wrote:
>>>
>>> 
>>>
>> I must try to do replacement or bring old behaviour of commit_manually() 
>>> with my custom wrapper. I'm trying to change code as less as possible.
>>>
>>
>> To be honest the "issues" you outlined here seem to suggest a bigger 
>> problem within your own code. I am aware that it is really hard and 
>> annoying to change from old style transactions to the new ones in big 
>> projects, but given the fact that atomic() just works and I have yet to see 
>> a project which used old style transactions properly (see Aymerics 
>> presentation on transactions), I think it is worth it.
>>  
>>
>>> You're asking what could be done better.. Generally speaking - an API 
>>> compatibility layer. As a maintainer of big and old project I would like to 
>>> import "commit_manually" from special module delivered with Django, which 
>>> will guarantee stability and compatibility.
>>>
>>
>> And defer upgrading to a proper transaction management for another few 
>> years? Seriously, if your project is to big to upgrade stick with 1.4 and 
>> use a distribution which provides LTS support for it (but yes, ultimately 
>> you will have to switch, but from what I hear Redhat is going to support 
>> 1.4 for another while :D)=…
>>
>> Cheers,
>> Florian
>>
>

-- 
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 post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/4bb9107e-767c-465e-974c-f24848f9d41d%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: How to disable system check framework?

[Marcin Nowak]

No, there is not problem in this code only, but yeah - it is a big problem. 
Real problem is that newer versions of Django are pushing developers to do 
things by the only one way, which is good for blogs or cms, or maybe new 
and small projects. As the result it is getting harder to maintain complex 
project based on Django unless you stay with old-and-unsupported version. 
And I'm not talking about atomic(), which is good and simple.

> And defer upgrading to a proper transaction management for another few 
years?

No. Just provide old-style wrappers (at the python-level api compatibility) 
for old guys maintaining old projects ;)

I can say something similar about generics views based on CBV - function 
based wrappers can be built top of CBV and can be provided in django.compat 
or django.legacy package. Just suggesting.
 
Cheers,
Marcin

On Wednesday, August 5, 2015 at 5:28:39 PM UTC+2, Florian Apolloner wrote:
>
> On Wednesday, August 5, 2015 at 3:59:39 PM UTC+2, Marcin Nowak wrote:
>>
>> 
>>
> I must try to do replacement or bring old behaviour of commit_manually() 
>> with my custom wrapper. I'm trying to change code as less as possible.
>>
>
> To be honest the "issues" you outlined here seem to suggest a bigger 
> problem within your own code. I am aware that it is really hard and 
> annoying to change from old style transactions to the new ones in big 
> projects, but given the fact that atomic() just works and I have yet to see 
> a project which used old style transactions properly (see Aymerics 
> presentation on transactions), I think it is worth it.
>  
>
>> You're asking what could be done better.. Generally speaking - an API 
>> compatibility layer. As a maintainer of big and old project I would like to 
>> import "commit_manually" from special module delivered with Django, which 
>> will guarantee stability and compatibility.
>>
>
> And defer upgrading to a proper transaction management for another few 
> years? Seriously, if your project is to big to upgrade stick with 1.4 and 
> use a distribution which provides LTS support for it (but yes, ultimately 
> you will have to switch, but from what I hear Redhat is going to support 
> 1.4 for another while :D)=…
>
> Cheers,
> Florian
>

-- 
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 post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/c2fc9c5a-dc87-49e2-aed3-064a3e2135b9%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: How to disable system check framework?

[Florian Apolloner]

On Wednesday, August 5, 2015 at 3:59:39 PM UTC+2, Marcin Nowak wrote:
>
> 
>
I must try to do replacement or bring old behaviour of commit_manually() 
> with my custom wrapper. I'm trying to change code as less as possible.
>

To be honest the "issues" you outlined here seem to suggest a bigger 
problem within your own code. I am aware that it is really hard and 
annoying to change from old style transactions to the new ones in big 
projects, but given the fact that atomic() just works and I have yet to see 
a project which used old style transactions properly (see Aymerics 
presentation on transactions), I think it is worth it.
 

> You're asking what could be done better.. Generally speaking - an API 
> compatibility layer. As a maintainer of big and old project I would like to 
> import "commit_manually" from special module delivered with Django, which 
> will guarantee stability and compatibility.
>

And defer upgrading to a proper transaction management for another few 
years? Seriously, if your project is to big to upgrade stick with 1.4 and 
use a distribution which provides LTS support for it (but yes, ultimately 
you will have to switch, but from what I hear Redhat is going to support 
1.4 for another while :D)=…

Cheers,
Florian

-- 
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 post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/ade4b6f6-14e2-412e-bd42-ad725df96bf2%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: How to disable system check framework?

[Marcin Nowak]

It's ok. I think that the thread can be closed, except the suggestion of 
making compatibility layer, which is rather a kind of Django`s philosophy 
and may be continued in a new thread (if needed).



On Wednesday, August 5, 2015 at 4:08:53 PM UTC+2, Carlton wrote:
>
> Sorry to be a pain but, could this thread be continued (if it's going to 
> be) on Django Users?
>
> (sorry)
>
> —
>
>
>
> On Wed, Aug 5, 2015 at 3:59 PM, Marcin Nowak  > wrote:
>
>> Hi Aymeric,
>>
>> This project is complex, as I said before, and works well with Django 
>> 1.4. But we need to upgrade it to newer version because of lack of support, 
>> security issues, and simplifcation of maintenance and growth (we're 
>> currently using three different Django versions, from 1.4 to 1.7, and we've 
>> decided to upgrade all subprojects to 1.8)
>>
>> commit_manually() is used within long-live processes running as a mgmt 
>> commands, where is used multiprocessing too.
>> Whole process is complicated and hard to maintain. I would like to avoid 
>> logical / flow changes, whose are required to replace commit_manually() 
>> with atomic().
>> Second use case is a extract-transform-load subsytem, which also requires 
>> precise development of queries, commits and rollbacks. I'm afraid that 
>> upgrade of it may be also hard.
>>
>> I think that there are rare cases, when manual transaction handling is 
>> required and should be available for punctilious developer.
>> *BUT* I can't say that atomic() does not fit my needs. I know how it 
>> work (I belive), but it may not cover current cases (implementation).
>>
>> I must try to do replacement or bring old behaviour of commit_manually() 
>> with my custom wrapper. I'm trying to change code as less as possible.
>>
>> You're asking what could be done better.. Generally speaking - an API 
>> compatibility layer. As a maintainer of big and old project I would like to 
>> import "commit_manually" from special module delivered with Django, which 
>> will guarantee stability and compatibility. This may be even undocumented. 
>> Manual commit() and rollback() functions are provided in transaction module 
>> (thanks so much for that!), so making compat layer should be possible, I 
>> think.
>>
>> Kind Regards,
>> Marcin
>>
>> On Wednesday, August 5, 2015 at 1:16:38 PM UTC+2, Aymeric Augustin wrote:
>>>
>>> On 5 août 2015, at 11:09, Marcin Nowak  wrote: 
>>>
>>> > I'm using commit_manually() frequently, but this decorator was 
>>> removed... 
>>>
>>> Hi Marcin, 
>>>
>>> Sorry for derailing the discussion a bit, but could you clarify why you 
>>> were 
>>> using this API? I removed it after failing to find a use case where it 
>>> would 
>>> be preferrable to commit_on_success(). I’d love to know if I missed 
>>> something 
>>> in order to avoid making similar mistakes again. 
>>>
>>> Using commit_manually() properly required great care -- and a 
>>> try/finally 
>>> construct in practice -- to ensure that no code path escaped without a 
>>> commit 
>>> or a rollback. It also required a massive amount of boilerplate to avoid 
>>> masking exceptions: 
>>>
>>> - 
>>> https://groups.google.com/d/msg/django-developers/S3a5UAqAsmg/7C27UGl6G_0J 
>>> - https://code.djangoproject.com/ticket/6623 
>>>
>>> If you replace it with transaction.atomic() and remove the boilerplate, 
>>> you 
>>> get the same behavior with ten times less code. 
>>>
>>> In case removing the boilerplate creates too much code churn, I 
>>> documented a 
>>> real drop-in replacement that doesn't have the drawbacks of 
>>> commit_manually: 
>>> https://docs.djangoproject.com/en/1.6/topics/db/transactions/#id5 
>>>
>>> What could I have done better? 
>>>
>>> If you don't want any changes in Django -- your posts to this list are 
>>> often 
>>> after-the-fact complains about new features -- perhaps you could stick 
>>> with 
>>> whatever version of Django you're currently running? 
>>>
>>> -- 
>>> Aymeric. 
>>>
>>>
>>>
>>>
>>> -- 
>> 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-develop...@googlegroups.com .
>> To post to this group, send email to django-d...@googlegroups.com 
>> .
>> Visit this group at http://groups.google.com/group/django-developers.
>> To view this discussion on the web visit 
>> https://groups.google.com/d/msgid/django-developers/3257c139-f52e-422f-8eb4-5a97771ca367%40googlegroups.com
>>  
>> 
>> .
>> For more options, visit https://groups.google.com/d/optout.
>>
>
>

-- 
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-develo

Re: How to disable system check framework?

[Carlton Gibson]

Sorry to be a pain but, could this thread be continued (if it's going to be) on 
Django Users?




(sorry)



—

On Wed, Aug 5, 2015 at 3:59 PM, Marcin Nowak 
wrote:

> Hi Aymeric,
> This project is complex, as I said before, and works well with Django 1.4. 
> But we need to upgrade it to newer version because of lack of support, 
> security issues, and simplifcation of maintenance and growth (we're 
> currently using three different Django versions, from 1.4 to 1.7, and we've 
> decided to upgrade all subprojects to 1.8)
> commit_manually() is used within long-live processes running as a mgmt 
> commands, where is used multiprocessing too.
> Whole process is complicated and hard to maintain. I would like to avoid 
> logical / flow changes, whose are required to replace commit_manually() 
> with atomic().
> Second use case is a extract-transform-load subsytem, which also requires 
> precise development of queries, commits and rollbacks. I'm afraid that 
> upgrade of it may be also hard.
> I think that there are rare cases, when manual transaction handling is 
> required and should be available for punctilious developer.
> *BUT* I can't say that atomic() does not fit my needs. I know how it work 
> (I belive), but it may not cover current cases (implementation).
> I must try to do replacement or bring old behaviour of commit_manually() 
> with my custom wrapper. I'm trying to change code as less as possible.
> You're asking what could be done better.. Generally speaking - an API 
> compatibility layer. As a maintainer of big and old project I would like to 
> import "commit_manually" from special module delivered with Django, which 
> will guarantee stability and compatibility. This may be even undocumented. 
> Manual commit() and rollback() functions are provided in transaction module 
> (thanks so much for that!), so making compat layer should be possible, I 
> think.
> Kind Regards,
> Marcin
> On Wednesday, August 5, 2015 at 1:16:38 PM UTC+2, Aymeric Augustin wrote:
>>
>> On 5 août 2015, at 11:09, Marcin Nowak > 
>> wrote: 
>>
>> > I'm using commit_manually() frequently, but this decorator was 
>> removed... 
>>
>> Hi Marcin, 
>>
>> Sorry for derailing the discussion a bit, but could you clarify why you 
>> were 
>> using this API? I removed it after failing to find a use case where it 
>> would 
>> be preferrable to commit_on_success(). I’d love to know if I missed 
>> something 
>> in order to avoid making similar mistakes again. 
>>
>> Using commit_manually() properly required great care -- and a try/finally 
>> construct in practice -- to ensure that no code path escaped without a 
>> commit 
>> or a rollback. It also required a massive amount of boilerplate to avoid 
>> masking exceptions: 
>>
>> - 
>> https://groups.google.com/d/msg/django-developers/S3a5UAqAsmg/7C27UGl6G_0J 
>> - https://code.djangoproject.com/ticket/6623 
>>
>> If you replace it with transaction.atomic() and remove the boilerplate, 
>> you 
>> get the same behavior with ten times less code. 
>>
>> In case removing the boilerplate creates too much code churn, I documented 
>> a 
>> real drop-in replacement that doesn't have the drawbacks of 
>> commit_manually: 
>> https://docs.djangoproject.com/en/1.6/topics/db/transactions/#id5 
>>
>> What could I have done better? 
>>
>> If you don't want any changes in Django -- your posts to this list are 
>> often 
>> after-the-fact complains about new features -- perhaps you could stick 
>> with 
>> whatever version of Django you're currently running? 
>>
>> -- 
>> Aymeric. 
>>
>>
>>
>>
>>
> -- 
> 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 post to this group, send email to django-developers@googlegroups.com.
> Visit this group at http://groups.google.com/group/django-developers.
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/django-developers/3257c139-f52e-422f-8eb4-5a97771ca367%40googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.

-- 
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 post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/1438783672435.73354761%40Nodemailer.
For more options, visit https://groups.google.com/d/optout.

Re: How to disable system check framework?

[Marcin Nowak]

Hi Aymeric,

This project is complex, as I said before, and works well with Django 1.4. 
But we need to upgrade it to newer version because of lack of support, 
security issues, and simplifcation of maintenance and growth (we're 
currently using three different Django versions, from 1.4 to 1.7, and we've 
decided to upgrade all subprojects to 1.8)

commit_manually() is used within long-live processes running as a mgmt 
commands, where is used multiprocessing too.
Whole process is complicated and hard to maintain. I would like to avoid 
logical / flow changes, whose are required to replace commit_manually() 
with atomic().
Second use case is a extract-transform-load subsytem, which also requires 
precise development of queries, commits and rollbacks. I'm afraid that 
upgrade of it may be also hard.

I think that there are rare cases, when manual transaction handling is 
required and should be available for punctilious developer.
*BUT* I can't say that atomic() does not fit my needs. I know how it work 
(I belive), but it may not cover current cases (implementation).

I must try to do replacement or bring old behaviour of commit_manually() 
with my custom wrapper. I'm trying to change code as less as possible.

You're asking what could be done better.. Generally speaking - an API 
compatibility layer. As a maintainer of big and old project I would like to 
import "commit_manually" from special module delivered with Django, which 
will guarantee stability and compatibility. This may be even undocumented. 
Manual commit() and rollback() functions are provided in transaction module 
(thanks so much for that!), so making compat layer should be possible, I 
think.

Kind Regards,
Marcin

On Wednesday, August 5, 2015 at 1:16:38 PM UTC+2, Aymeric Augustin wrote:
>
> On 5 août 2015, at 11:09, Marcin Nowak > 
> wrote: 
>
> > I'm using commit_manually() frequently, but this decorator was 
> removed... 
>
> Hi Marcin, 
>
> Sorry for derailing the discussion a bit, but could you clarify why you 
> were 
> using this API? I removed it after failing to find a use case where it 
> would 
> be preferrable to commit_on_success(). I’d love to know if I missed 
> something 
> in order to avoid making similar mistakes again. 
>
> Using commit_manually() properly required great care -- and a try/finally 
> construct in practice -- to ensure that no code path escaped without a 
> commit 
> or a rollback. It also required a massive amount of boilerplate to avoid 
> masking exceptions: 
>
> - 
> https://groups.google.com/d/msg/django-developers/S3a5UAqAsmg/7C27UGl6G_0J 
> - https://code.djangoproject.com/ticket/6623 
>
> If you replace it with transaction.atomic() and remove the boilerplate, 
> you 
> get the same behavior with ten times less code. 
>
> In case removing the boilerplate creates too much code churn, I documented 
> a 
> real drop-in replacement that doesn't have the drawbacks of 
> commit_manually: 
> https://docs.djangoproject.com/en/1.6/topics/db/transactions/#id5 
>
> What could I have done better? 
>
> If you don't want any changes in Django -- your posts to this list are 
> often 
> after-the-fact complains about new features -- perhaps you could stick 
> with 
> whatever version of Django you're currently running? 
>
> -- 
> Aymeric. 
>
>
>
>
>

-- 
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 post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/3257c139-f52e-422f-8eb4-5a97771ca367%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: How to disable system check framework?

[Aymeric Augustin]

On 5 août 2015, at 11:09, Marcin Nowak  wrote:

> I'm using commit_manually() frequently, but this decorator was removed... 

Hi Marcin,

Sorry for derailing the discussion a bit, but could you clarify why you were
using this API? I removed it after failing to find a use case where it would
be preferrable to commit_on_success(). I’d love to know if I missed something
in order to avoid making similar mistakes again.

Using commit_manually() properly required great care -- and a try/finally
construct in practice -- to ensure that no code path escaped without a commit
or a rollback. It also required a massive amount of boilerplate to avoid
masking exceptions:

- https://groups.google.com/d/msg/django-developers/S3a5UAqAsmg/7C27UGl6G_0J
- https://code.djangoproject.com/ticket/6623

If you replace it with transaction.atomic() and remove the boilerplate, you
get the same behavior with ten times less code.

In case removing the boilerplate creates too much code churn, I documented a
real drop-in replacement that doesn't have the drawbacks of commit_manually:
https://docs.djangoproject.com/en/1.6/topics/db/transactions/#id5

What could I have done better?

If you don't want any changes in Django -- your posts to this list are often
after-the-fact complains about new features -- perhaps you could stick with
whatever version of Django you're currently running?

-- 
Aymeric.




-- 
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 post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/76ACD788-8644-40E3-A01E-5C8BEB81FCD4%40polytechnique.org.
For more options, visit https://groups.google.com/d/optout.

Re: How to disable system check framework?

[Marcin Nowak]

Thank, Josh.

I'm upgrading mature and complex project, which have some tricky parts 
implemented like a monkey-patched user model, which is applied after system 
chceck execution. So Django complains about missing fields in ModelAdmin, 
but patch works fine. There were some complains about doubled mappings to 
fields, but I've removed them. Generally speaking I don't need System 
Check, because I can find soultion myself other way.

Migrations are similar - they are too simple/limited for my needs. They 
operate on models, but I'm working mainly with database and I'm creating 
mappings for tables and views for easy querying. So I don't need builtin 
migrations feature.

I'm using commit_manually() frequently, but this decorator was removed... 

And so on...

That's why I feel that working with Django is harder. It's more strict, 
useful tools/helpers are missing, there is more features which should be 
bypassed/omitted. I feel that is harder to do simple things... Or maybe I'm 
getting old. ;)

Cheers,
Marcin


On Wednesday, August 5, 2015 at 3:08:26 AM UTC+2, Josh Smeaton wrote:
>
> Your "scare quotes" for "feature" are really disappointing. Especially 
> considering that the checks were hardcoded and couldn't be silenced prior 
> to the "system check framework".
>
> > Working with Django is getting harder with every new version.
>
> If you want to turn off new features or extension points, then I'd imagine 
> there'd be more work than for the regular user. Otherwise, I couldn't 
> disagree more.
>
> Anyhow, you want to turn off system checks for some reason. Here are some 
> potential ways forward:
>
> - Target the checks that are incorrectly spitting out errors or warnings, 
> and fix those.
> - Provide another setting "DISABLE_CHECKS" or something similar that will 
> prevent checks running altogether (probably not ideal, new settings are 
> hard to get into core, especially when the benefit here is still 
> questionable).
> - Provide a special value for the existing SILENCED_SYSTEM_CHECKS setting 
> that causes all checks to be silenced.
>
> You haven't really said much about the issue other than it bothers you. 
> The main purpose of checks are for development - so it doesn't have any 
> runtime or deployment time penalties. Perhaps if you took some time to 
> justify why users other than yourself might want to disable the check 
> framework, it'd be easier to start looking at solutions to problems.
>
> Cheers
>
>
> On Wednesday, 5 August 2015 01:16:21 UTC+10, Marcin Nowak wrote:
>>
>> Thanks, Carl. I know about silencing but I want to disable unwanted 
>> "feature". Working with Django is getting harder with every new version. 
>>
>>
>> On Tuesday, August 4, 2015 at 3:25:22 PM UTC+2, Carl Meyer wrote:
>>>
>>>
>>> > On Aug 4, 2015, at 9:18 AM, Marcin Nowak  
>>> wrote: 
>>> > 
>>> > I need to upgrade project to Django 1.8 but the SystemCheck Framework 
>>> bothers me. 
>>> > It complains about thigs that should work, even if they are a little 
>>> tricky. 
>>> > 
>>> > I need to disable system checks designed for blogs and other simple 
>>> sites. How can I do that? 
>>>
>>> The third paragraph of the system checks documentation [1] links to [2]. 
>>>
>>> Also, this is a question about using Django, not developing Django, so 
>>> it belongs on the django-users mailing list, not here. 
>>>
>>> Carl 
>>>
>>> [1] https://docs.djangoproject.com/en/1.8/topics/checks/ 
>>> [2] 
>>> https://docs.djangoproject.com/en/1.8/ref/settings/#std:setting-SILENCED_SYSTEM_CHECKS
>>
>>

-- 
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 post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/47132c06-4617-4119-b8f0-b0f166df2103%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: How to disable system check framework?

[Josh Smeaton]

Your "scare quotes" for "feature" are really disappointing. Especially 
considering that the checks were hardcoded and couldn't be silenced prior 
to the "system check framework".

> Working with Django is getting harder with every new version.

If you want to turn off new features or extension points, then I'd imagine 
there'd be more work than for the regular user. Otherwise, I couldn't 
disagree more.

Anyhow, you want to turn off system checks for some reason. Here are some 
potential ways forward:

- Target the checks that are incorrectly spitting out errors or warnings, 
and fix those.
- Provide another setting "DISABLE_CHECKS" or something similar that will 
prevent checks running altogether (probably not ideal, new settings are 
hard to get into core, especially when the benefit here is still 
questionable).
- Provide a special value for the existing SILENCED_SYSTEM_CHECKS setting 
that causes all checks to be silenced.

You haven't really said much about the issue other than it bothers you. The 
main purpose of checks are for development - so it doesn't have any runtime 
or deployment time penalties. Perhaps if you took some time to justify why 
users other than yourself might want to disable the check framework, it'd 
be easier to start looking at solutions to problems.

Cheers


On Wednesday, 5 August 2015 01:16:21 UTC+10, Marcin Nowak wrote:
>
> Thanks, Carl. I know about silencing but I want to disable unwanted 
> "feature". Working with Django is getting harder with every new version. 
>
>
> On Tuesday, August 4, 2015 at 3:25:22 PM UTC+2, Carl Meyer wrote:
>>
>>
>> > On Aug 4, 2015, at 9:18 AM, Marcin Nowak  wrote: 
>> > 
>> > I need to upgrade project to Django 1.8 but the SystemCheck Framework 
>> bothers me. 
>> > It complains about thigs that should work, even if they are a little 
>> tricky. 
>> > 
>> > I need to disable system checks designed for blogs and other simple 
>> sites. How can I do that? 
>>
>> The third paragraph of the system checks documentation [1] links to [2]. 
>>
>> Also, this is a question about using Django, not developing Django, so it 
>> belongs on the django-users mailing list, not here. 
>>
>> Carl 
>>
>> [1] https://docs.djangoproject.com/en/1.8/topics/checks/ 
>> [2] 
>> https://docs.djangoproject.com/en/1.8/ref/settings/#std:setting-SILENCED_SYSTEM_CHECKS
>
>

-- 
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 post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/14d4f121-2e75-4f35-b8ef-ced371060f5e%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: How to disable system check framework?

[Marcin Nowak]

Thanks, Carl. I know about silencing but I want to disable unwanted 
"feature". Working with Django is getting harder with every new version. 


On Tuesday, August 4, 2015 at 3:25:22 PM UTC+2, Carl Meyer wrote:
>
>
> > On Aug 4, 2015, at 9:18 AM, Marcin Nowak  > wrote: 
> > 
> > I need to upgrade project to Django 1.8 but the SystemCheck Framework 
> bothers me. 
> > It complains about thigs that should work, even if they are a little 
> tricky. 
> > 
> > I need to disable system checks designed for blogs and other simple 
> sites. How can I do that? 
>
> The third paragraph of the system checks documentation [1] links to [2]. 
>
> Also, this is a question about using Django, not developing Django, so it 
> belongs on the django-users mailing list, not here. 
>
> Carl 
>
> [1] https://docs.djangoproject.com/en/1.8/topics/checks/ 
> [2] 
> https://docs.djangoproject.com/en/1.8/ref/settings/#std:setting-SILENCED_SYSTEM_CHECKS

-- 
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 post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/6bf13f68-a2ca-4c1d-95d7-314a10d95c10%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: How to disable system check framework?

[Carl Meyer]

> On Aug 4, 2015, at 9:18 AM, Marcin Nowak  wrote:
> 
> I need to upgrade project to Django 1.8 but the SystemCheck Framework bothers 
> me.
> It complains about thigs that should work, even if they are a little tricky.
> 
> I need to disable system checks designed for blogs and other simple sites. 
> How can I do that?

The third paragraph of the system checks documentation [1] links to [2].

Also, this is a question about using Django, not developing Django, so it 
belongs on the django-users mailing list, not here. 

Carl

[1] https://docs.djangoproject.com/en/1.8/topics/checks/
[2] 
https://docs.djangoproject.com/en/1.8/ref/settings/#std:setting-SILENCED_SYSTEM_CHECKS

-- 
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 post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/5CA4CB28-D731-4E4C-82EF-80FCC2F1C47B%40oddbird.net.
For more options, visit https://groups.google.com/d/optout.

How to disable system check framework?

[Marcin Nowak]

Hi,

I need to upgrade project to Django 1.8 but the SystemCheck Framework 
bothers me.
It complains about thigs that should work, even if they are a little tricky.

I need to disable system checks designed for blogs and other simple sites. 
How can I do that?

Best Regards,
Marcin

-- 
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 post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/66320218-db2c-4861-afdd-0592b0ba3861%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: System check framework

[Russell Keith-Magee]

Hi Chris,

On Sat, Sep 21, 2013 at 4:07 AM, Christopher Medrela <
chris.medr...@gmail.com> wrote:

> Hello!
>
> This summer I'm a student of Google Summer of Code. I was working at
> introducing a new system check framework (merging django-secure was a part
> of
> my proposal, but I didn't manage to do it due to my time overestimation).
> The
> project is coming to the end and there is a pull request [1] that is almost
> ready for merging. I would like to present you with the capabilities of the
> framework as well as a high-level overview. I would like to hear your
> opinion
> how the framework can be improved -- this is a last chance for that! This
> thread is a continuation of old "[GSoC] Revamping validation framework and
> merging django-secure once again" thread [2].
>
> [1] https://github.com/django/django/pull/1364
> [2] https://groups.google.com/forum/#!topic/django-developers/fEf21dtpqDE
>
> Here I would like to say thank you to my mentor, Russell Keith-Magee, who
> gave
> me a lot of advices, kept an eye at my project, did reviews and supported
> me.
> Preston Holmes also spent a lot of time reviewing code. Many thanks to
> numerous other contributors!
>

Let me repeat publicly what I said to you on our last call -- Thank *you*
for your efforts over the summer. It was a pleasure to work with you, and
you deserve to be proud of what you've produced.

It's certainly a pity that we didn't get to merging django-secure, but the
codebase you've provided gives us a very strong foundation on which to do
that merge as a post-GSoC activity.

So - now the pressure is on me to do a final review and commit! In the
meantime, I'd encourage anyone with an interest to look over the pull
request and provide feedback.

Yours,
Russ Magee %-)

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.
For more options, visit https://groups.google.com/groups/opt_out.

System check framework

[Christopher Medrela]

Hello!

This summer I'm a student of Google Summer of Code. I was working at
introducing a new system check framework (merging django-secure was a part 
of
my proposal, but I didn't manage to do it due to my time overestimation). 
The
project is coming to the end and there is a pull request [1] that is almost
ready for merging. I would like to present you with the capabilities of the
framework as well as a high-level overview. I would like to hear your 
opinion
how the framework can be improved -- this is a last chance for that! This
thread is a continuation of old "[GSoC] Revamping validation framework and
merging django-secure once again" thread [2].

[1] https://github.com/django/django/pull/1364
[2] https://groups.google.com/forum/#!topic/django-developers/fEf21dtpqDE

Here I would like to say thank you to my mentor, Russell Keith-Magee, who 
gave
me a lot of advices, kept an eye at my project, did reviews and supported 
me.
Preston Holmes also spent a lot of time reviewing code. Many thanks to
numerous other contributors!

Now let me introduce you the framework.

*Overview*

I've introduced a new system check framework that replaces the old 
validation
framework performing mainly model validation. The new framework is 
responsible
for model validation, app-specific checks like ModelAdmin validation as well
as compatibility checks. It introduces concept of warnings. Warnings as well
as errors can be silenced. The framework is open-ended which means that you
can register your own check stuff.

*Messages*

The framework uses a concept of messages similar to messages from message
framework or logging framework. A message can be a light message like a
warning, info or debug; or a serious message, e.g. an error or critical
(error). Every message consists of four attributes:

   - required error message (`msg`);
   - optional `hint`; in order to force developers to think carefully if 
   they
   cannot provide any useful hint, they need to explicitly pass hint=None in
   that case;
   - optional invalid object (`obj`);
   - optional unique message identifier (`id`) used to refer to messages, 
   i.e.
   "E001" (a core error) or "admin.W001" (a warning issued by admin app).

*Performing checks*

In order to perform all kinds of checks, type:

python manage.py check

This command does the same stuff as the old `validate` and `check` commands.
`validate` is now deprecated and delegates to `check` command.

You can still validate some specific apps:

python manage.py check admin auth

Or you can run a subset of checks labeled with a given tag:

python manage.py -t compatibility  # alternative: --tag compatibility

*Silencing errors/warnings*

A new setting called SILENCED_SYSTEM_CHECKS was introduced. It's a list of
message identifiers. If you put on the list a light message like a warning, 
it
won't be printed anymore. Putting on the list a serious message like an 
error
won't hide the message, but will allow you to i.e. run server.

*Registering your own stuff*

If you want to add a new check, you need to write a function that accepts
`apps` and `**kwargs` arguments where `apps` is a list of applications that
should be validated (or None if all apps should be validated). The function
should return a list of messages, even if it's an empty list. Finally, you
need to register this entry point. Let's look at this snippet implementing
some security checks:

from django.conf import settings
from django.core import checks

# Label this entry point with 'security' tag. This tag can be used while
# invoking check command, e.g. you can write `./manage.py -t security`.
@checks.register('security')
def my_security_check(apps, **kwargs):
# This check does not perform any app-specific checks, so if we are
# asked to validate some specific apps, we can skip checks.
if apps is not None:
return []

if len(settings.SECRET_KEY) < 64:
return [
checks.Warning(
'Your SECRET_KEY is too short.',
hint=None,  # need to explicitly pass hint even if you 
cannot provide any hint
obj='settings.SECRET_KEY',
id='security.W001',
)
]
else:
return []

*Field/model/manager checks*

You don't have to register your check stuff if it's called from another 
piece
of code that is registered (directly or indirectly). This is true especially
in the case of fields, models and managers. Each of these object have 
`check`
method (or classmethod in the case of models) that can be overriden in order
to add some validation stuff. Consider that you implemented a field that
accepts only values from [min, max] range and you want to check if min < 
max.
Here is a snippet of code:

from djang

Re: System check framework

[Carl Meyer]

Hi Christopher,

On 09/20/2013 02:07 PM, Christopher Medrela wrote:
> This summer I'm a student of Google Summer of Code. I was working at
> introducing a new system check framework (merging django-secure was a
> part of
> my proposal, but I didn't manage to do it due to my time
> overestimation). The
> project is coming to the end and there is a pull request [1] that is almost
> ready for merging. I would like to present you with the capabilities of the
> framework as well as a high-level overview. I would like to hear your
> opinion
> how the framework can be improved -- this is a last chance for that! This
> thread is a continuation of old "[GSoC] Revamping validation framework and
> merging django-secure once again" thread [2].
> 
> [1] https://github.com/django/django/pull/1364
> [2] https://groups.google.com/forum/#!topic/django-developers/fEf21dtpqDE
> 
> Here I would like to say thank you to my mentor, Russell Keith-Magee,
> who gave
> me a lot of advices, kept an eye at my project, did reviews and
> supported me.
> Preston Holmes also spent a lot of time reviewing code. Many thanks to
> numerous other contributors!
> 
> Now let me introduce you the framework.

I haven't had the time this summer to keep up with your progress, but
based on your summary here, this looks really excellent! Thanks for your
work.

Carl

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.
For more options, visit https://groups.google.com/groups/opt_out.