On Sat, Aug 22, 2015 at 8:28 PM, Tim Graham wrote:
> I agree it would be great to get some help running the Django tests on
> Windows. I run them in a local virtual machine every so often, but I would
> love to be able to delegate fixing Windows issues. Meet, can your team
Absolutely agree with Tim here. We need to start exploring all the cool
open sourced third party adapters. Borrowing/adopting them definitely seems
like the way to go about things instead of re inventing the wheel. I tried
doing some research and came across the following:
1. Django-mssql
Thanks for taking this on, James. I do think it would be best to defer this
to Django 1.10 rather than try to rush it into Django 1.9 at this point.
Also, there are several URL related deprecations scheduled to complete in
1.10 which should simplify things (I've started on those removals here:
In the interests of keeping the excellent work done by Marten Kenbeek (knbk
on IRC/Github) on the GSOC 2015 URL Dispatcher project [1] current and
moving along, I've created a new branch [2] and rebased it against current
master. (I am doing this because it seems like Marten is no longer able
>
>
>> 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
>
Dear devs
I'm the PR mentioned contributor.
While I understand your concern about translated content in the database and
the other ticket mentioned (having the info stored as Json or yaml)
I see that these are different ways and are not mutually exclusive.
The issue mentioned regards having
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,
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.
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?
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
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
Hello Kishan,
This is off-topic for the django-developers mailing-list, which is dedicated to
the development of Django itself. Please send usage questions to django-users.
The docs for Oscar’s get_core_apps() answer your question:
>
> The main problem I see with this is that it allows one app to mess with
> other
> apps' models (yes, it means I think modeltranslations is Doing It
> Wrong(tm),
> and the current issue is just pointing that out more loudly).
I agree that allowing apps to mess with other apps' models
I have been working on a e commerce website. I am using django-oscar 1.1
for this. Here is my installed app looks like :
INSTALLED_APPS = [
'django.contrib.admin',
'django.contrib.auth',
'django.contrib.contenttypes',
'django.contrib.sessions',
'django.contrib.messages',
Gotcha.
So, F objects seem to be pretty good as generic interface to specify query
paths, the only remaining patch - adding select_related and
prefetch_related support. I'll preapare a preliminary pull request soon.
On Tuesday, August 25, 2015 at 2:48:10 AM UTC+3, Josh Smeaton wrote:
>
>
On Mon, Aug 24, 2015 at 10:19 PM, Emmanuelle Delescolle <
delesco...@gmail.com> wrote:
> I've been using this solution on a couple projects (including ones with
> several children to the same migration) and have never had troubles with
> the migration solver, I guess I have been lucky.
>
> I'll
On Tuesday 25 August 2015 05:13:14 Andrew Godwin wrote:
> The main problem I forsee here is just making sure that the MigrationLoader
> knows to take these located-in-the-wrong-place migrations and insert them
> into the migration tree right - in particular, you have issues with the
>
On Tuesday, August 25, 2015 at 1:48:55 AM UTC+2, Tim Graham wrote:
>
> Do you like the idea to use form field labels in the admin history
> messages instead of the form field names themselves?
>
> It's been implemented here:
> https://github.com/django/django/pull/5169
>
On Monday, August 24, 2015 at 3:30:56 PM UTC+2, Krzysio Gutkowski wrote:
>
> Hi,
>
> It looks that implementing it in that ways makes more sense.
>
> However, if I were to implement it in that way, should I change both
> settings in one PR, or should I rework the LOCALE_PATHS setting in a
>
22 matches
Mail list logo