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
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
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 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,
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,
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
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
>
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 "
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
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.
@gmail.com
> > 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" oper
omated 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 -
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 sma
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
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
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
, 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
oved 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 problem
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
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 monkeypatch
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
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:
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
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
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,
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
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,
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
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
>
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 t
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:
> >
> 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
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
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 propo
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
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
>
40 matches
Mail list logo