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
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 r
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:
> >
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 or
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 i
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, Marci
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
>
>
>> 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, Dja
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
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
> monkeypatch
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
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 c
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.
>
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.djangoproje
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 fi
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 h
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 check
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 reas
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
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
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.E
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
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
li
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
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_autocomm
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
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 compl
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
pr
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, coul
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 ver
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
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 pref
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
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 poi
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 p
> 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
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 receive
37 matches
Mail list logo