Re: Improving MSSQL and Azure SQL support on Django

[Russell Keith-Magee]

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
> provide ongoing help with fixing Windows-specific issues in Django, even if
> they aren't related to MSSQL/Azure? That is something where we've had a
> hard time finding volunteers to help with and is obviously important if we
> want to claim 1st-class support for Windows.
>
> I don't have any experience with MSSQL/Azure, but I could probably attend
> the October 13-15 event at Microsoft if you think my participation would be
> valuable and if the DSF were to approve the time commitment as part of the
> fellow duties.
>

I don't see why this would be a problem - I'll run it past the fellowship
committee and get their OK.

Russ %-)

-- 
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/CAJxq849qoYOBLgruGUmS%3DdVf6pXbsAoZhHW-aj5%2BQL6tnp0n-g%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Improving MSSQL and Azure SQL support on Django

[Meet Bhagdev]

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 

2. Django-pymssql 

3. Django-pyodbc-azure 

4. Django-pyodbc 


Am I missing any? 

Best,
Meet

On Monday, August 24, 2015 at 11:12:44 AM UTC-7, Tim Graham wrote:
>
> I guess the first step is to identify which third-party backend(s) we'll 
> target to adopt officially (or at least borrow from heavily). For example, 
> will we need separate backends for MSSQL and Azure? (Knowing nothing about 
> the landscape myself, this question could be nonsensical.) Is this 
> discussion something that should happen before the October summit? It seems 
> to me the face-to-face time will likely be more productive if we have some 
> of the high-level details ironed out.
>
> By the way, is videoconferencing an option for Django developers 
> interested in participating in the discussion at that time but unable to 
> travel to Seattle?
>
> On Saturday, August 22, 2015 at 5:53:37 PM UTC-4, Shai Berger wrote:
>>
>> On Saturday 22 August 2015 13:28:31 Aymeric Augustin wrote:
>>
>> > 
>>
>> > There isn’t such a clear story for running Django on Linux. This led me 
>> to
>>
>> > write https://github.com/aaugustin/django-pymssql. Alternatives include
>>
>> > https://github.com/denisenkom/django-sqlserver and
>>
>> > https://github.com/lionheart/django-pyodbc.
>>
>>  
>>
>> There's also django-pyodbc-azure 
>> , a fork of 
>> django-pyodbc (actually, the current django-pyodbc is also a fork of the 
>> original project, which has been discontinued). I took the liberty to 
>> forward the message to that project.
>>
>>  
>>
>> 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/dd576c92-474c-415d-b1a7-a2bc6df3baa7%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: URL Dispatcher

[Tim Graham]

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: 
https://github.com/django/django/pull/5143). Absent another interested 
person, I should be able to mentor you on this during the Django 1.10 
release cycle (which can start once we cut the stable/1.9.x branch after 
1.9 alpha around September 21). In the meantime, if you want take a look 
for some simpler tickets to tackle to get a feel for our contribution 
process, I think that would be helpful.

On Tuesday, August 25, 2015 at 2:25:07 PM UTC-4, James Addison wrote:
>
> 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 to continue working on the effort. *If this should change or is 
> incorrect, Marten, please let me/us know!*)
>
> To try and find how far along the project is, I've quickly compared the 
> original GSOC outline/timeline [1] against my updated branch [2] to see 
> what is done/remaining:
>
>- section 3.1 (Design phase) I believe was done, but am unable to find 
>anything other than a few posts on the django-developer mailing list - *is 
>there a source for this?*
>- section 3.2 (Namespace overhaul) hasn't been addressed that I can 
>tell - *I'd recommend dropping this as it isn't core to the effort*
>- Items completed in section 3.3 (Dispatcher API): 3.3.[1-4]
>- *Items remaining* in section 3.3: (Dispatcher API): 3.3.[5-9] - some 
>highlights:
>   - re-implementing some legacy functionality for backward 
>   compatibility (ie. RegexURLPattern)
>   - additional tests
>   - lots of documentation!
>   - additional resolvers (ie. scheme, sub-domain, etc)
>
>
>
> Please keep in mind that I'm mostly unfamiliar with the internals of 
> Django core elements, so I may have easily overlooked/mistook relevant 
> information. I'd appreciate any other review/input as well. Here is the 
> branch comparison [3] on Github.
>
> Based on the Django 1.9 release schedule, I have doubts that this will be 
> merged in for feature freeze, which is unfortunate. I would like to think 
> that I am up to the task, but the URL functionality in Django is about as 
> 'core' as it gets and I would not want to bite off more than I can chew 
> without backup. Any thoughts on the continued viability of this effort? Is 
> this something that someone inexperienced with Django internals should take 
> on? If so, I'd definitely need coaching!
>
> Lastly, I want to mention that I do have a new project in which I had been 
> using Marten's branch (and am now using my own branch [2]), and it has been 
> functionally solid for the scheme, (sub) domain and url resolving and 
> reversing use cases. See the the urls.py [4] from that project to whet 
> your appetites as to the possibilities of all this. :)
>
> Previous discussions on the django-developers mailing list [5].
>
> [1] 
> https://www.google-melange.com/gsoc/project/details/google/gsoc2015/knbk/5668600916475904
> [2] https://github.com/jaddison/django/tree/gsoc2015_url_dispatcher
> [3] 
> https://github.com/django/django/compare/master...jaddison:gsoc2015_url_dispatcher
> [4] https://gist.github.com/jaddison/18dea1bf93767f326aa5
> [5] 
> https://groups.google.com/forum/#!searchin/django-developers/marten/django-developers/IoivPLHJ_nw
>  
> and 
> https://groups.google.com/forum/#!searchin/django-developers/marten/django-developers/WQoJN_MGTOg
>  
> (most recent)
>
> Cheers,
> James Addison
>

-- 
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/5c0ff7fb-28ec-41c2-bb1a-8f76caf35ddc%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

URL Dispatcher

[James Addison]

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 to 
continue working on the effort. *If this should change or is incorrect, 
Marten, please let me/us know!*)

To try and find how far along the project is, I've quickly compared the 
original GSOC outline/timeline [1] against my updated branch [2] to see 
what is done/remaining:

   - section 3.1 (Design phase) I believe was done, but am unable to find 
   anything other than a few posts on the django-developer mailing list - *is 
   there a source for this?*
   - section 3.2 (Namespace overhaul) hasn't been addressed that I can tell 
   - *I'd recommend dropping this as it isn't core to the effort*
   - Items completed in section 3.3 (Dispatcher API): 3.3.[1-4]
   - *Items remaining* in section 3.3: (Dispatcher API): 3.3.[5-9] - some 
   highlights:
  - re-implementing some legacy functionality for backward 
  compatibility (ie. RegexURLPattern)
  - additional tests
  - lots of documentation!
  - additional resolvers (ie. scheme, sub-domain, etc)
   

   
Please keep in mind that I'm mostly unfamiliar with the internals of Django 
core elements, so I may have easily overlooked/mistook relevant 
information. I'd appreciate any other review/input as well. Here is the 
branch comparison [3] on Github.

Based on the Django 1.9 release schedule, I have doubts that this will be 
merged in for feature freeze, which is unfortunate. I would like to think 
that I am up to the task, but the URL functionality in Django is about as 
'core' as it gets and I would not want to bite off more than I can chew 
without backup. Any thoughts on the continued viability of this effort? Is 
this something that someone inexperienced with Django internals should take 
on? If so, I'd definitely need coaching!

Lastly, I want to mention that I do have a new project in which I had been 
using Marten's branch (and am now using my own branch [2]), and it has been 
functionally solid for the scheme, (sub) domain and url resolving and 
reversing use cases. See the the urls.py [4] from that project to whet your 
appetites as to the possibilities of all this. :)

Previous discussions on the django-developers mailing list [5].

[1] 
https://www.google-melange.com/gsoc/project/details/google/gsoc2015/knbk/5668600916475904
[2] https://github.com/jaddison/django/tree/gsoc2015_url_dispatcher
[3] 
https://github.com/django/django/compare/master...jaddison:gsoc2015_url_dispatcher
[4] https://gist.github.com/jaddison/18dea1bf93767f326aa5
[5] 
https://groups.google.com/forum/#!searchin/django-developers/marten/django-developers/IoivPLHJ_nw
 
and 
https://groups.google.com/forum/#!searchin/django-developers/marten/django-developers/WQoJN_MGTOg
 
(most recent)

Cheers,
James Addison

-- 
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/8fe229a5-4418-4d14-8f41-1bf8613e32c9%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: Okay to use form field labels in admin history?

[Ramez Ashraf]

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 multiple supported languages, while what the 
PR is solving is the simple "not english " site + the idea of having a 
customized label or clear verbose name instead of the current field name.

IMHO, I think this pull is a step forward. And when the issue mentioned is 
solved in an enhancement of the log structure, the old structure will continue 
to exist for backword compatibility. 

I call -if I may- a reconsideration. :) 

Last, I'm making extensive use of the admin in my work.. Hopefully I'll be 
around contributing in it.

Kind regards

-- 
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/b1f74548-a324-46a1-a126-06b7830b809e%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
>  
> 
> .
> 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 
> .
> 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 
> .

-- 
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: Django oscar core apps confilicts with my local apps

[Aymeric Augustin]

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:
http://django-oscar.readthedocs.org/en/latest/topics/customisation.html#replace-oscar-s-app-with-your-own-in-installed-apps
 


-- 
Aymeric.



> On 25 août 2015, at 09:11, Kishan Mehta  wrote:
> 
> 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',
> 'django.contrib.staticfiles',
> # local apps
> 'content',
> 'usermgmt',
> 'resources',
> 'assessment',
> 'analytics',
> 'utils',
> # 'notify',
> # Auth related apps
> 'oauth2_provider',
> 'social.apps.django_app.default',
> 'rest_framework_social_oauth2',
> # rest
> 'rest_framework',
> 'djoser',
> # misc - third party
> 'reversion',
> 'corsheaders',
> 'notifications',
> #oscar
> 'oscarapi',
> 
> 
> ] + get_core_apps()
> 
> 
> While running server : 
> 
> 
> 
> 
> 
> Traceback (most recent call last):
>  File "manage.py", line 10, in 
> execute_from_command_line(sys.argv)
>  File 
> "/home/rss-20/.virtualenvs/kishan_pal/local/lib/python3.4/site-packages/django/core/management/__init__.py",
>  line 338, in execute_from_command_line
> utility.execute()
> File 
> "/home/rss-20/.virtualenvs/kishan_pal/local/lib/python3.4/site-packages/django/core/management/__init__.py",
>  line 312, in execute
> django.setup()
> File 
> "/home/rss-20/.virtualenvs/kishan_pal/local/lib/python3.4/site-packages/django/__init__.py",
>  line 18, in setup
> apps.populate(settings.INSTALLED_APPS)
> File 
> "/home/rss-20/.virtualenvs/kishan_pal/local/lib/python3.4/site-packages/django/apps/registry.py",
>  line 89, in populate
> "duplicates: %s" % app_config.label)
>  django.core.exceptions.ImproperlyConfigured: Application labels aren't 
> unique, duplicates: analytics
> 
> 
> Aparently analystics is conflicting with the analytics in get_core_apps().
> 
> 
> 
> Is there any way to resolve this ?
> 
> 
> -- 
> 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/f949c181-3e6a-4ec5-9fda-f5e1b9b8f1a4%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/266CD6B6-A59F-4C1A-8D67-BB5F0F9DCA22%40polytechnique.org.
For more options, visit https://groups.google.com/d/optout.

Re: Ability to migrate other applications

[Emmanuelle Delescolle]

>
> 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 might be a 
problem that's why I believe this feature should be highlighted as 
dangerous or for "people who know what they are doing" but it's already 
possible to do that today anyways (just write raw sql in you migrations and 
you'll be able to mess with all the models you want).
Whether modeltranslations is doing right or wrong isn't the point, I took 
modeltranslations as a use-case as it is a widely used application. I've 
also had to resort to that feature with other applications or simply when 
trying to extract an application from a particular project to move it into 
a reusable app.


>> I'll throw a sample application today and try to reproduce the problem 
>> and see how it can be fixed/worked around. And write the appropriate tests.
>>
>>
> That would be great - I've not actually tried it, so you're ahead of me 
> there, just trying to think of things that might muck it up!
>

The project is available at 
https://bitbucket.org/emma_nuelle/migrate_othe_app_sample (I'll give a 
detailed explanation of what has been done at the bottom of this post). I 
have simply used "contribute_to_class" to trigger the desired behavior 
(modeltranslations isn't compatible with master anyways)

>
>  I still think Django should make it quite hard to do this and screamingly 
> obvious that you're going down a dark path, but at the same time we should 
> at least have it be possible.
>

Yes, I'm not sure what's the best way to do that, either inside the 
documentation or systematically throw a warning when running such 
migrations? 

The sample app:

   - up 
   until 
https://bitbucket.org/emma_nuelle/migrate_othe_app_sample/commits/1ecb71e8d428638bc8dffe8a0e9aae75fb20cd7f
 
   : setting things up
   - 
https://bitbucket.org/emma_nuelle/migrate_othe_app_sample/commits/18986dd7384f103f0cefeed94b0021998c3a21d0
 
   : I've used contribute_to_class to create a new field from the "unruly" 
   application on one of the models from the "pizzas" application and the ran 
   makmigrations.
   - 
https://bitbucket.org/emma_nuelle/migrate_othe_app_sample/commits/b70976ca4c953c0738ea250c731fefac2e7dff1e
 
   : the new migration initially created in "pizzas" has been moved to 
   "unruly" and the "migrated_app" property has been added to it. So far, no 
   problem
   - 
https://bitbucket.org/emma_nuelle/migrate_othe_app_sample/commits/fcce7491f6efe90d3a28cea471d6951ed756941b
 
   : the maintainer of "pizzas" has added a new migration. Running migrate 
   both on an empty db or on a pre-existing db work fine without having to run 
   --merge
   


   - up 
   until 
https://bitbucket.org/emma_nuelle/migrate_othe_app_sample/commits/668d6877de1f0b2efb6cecb24bf7fee93fc2f9c1
 
   : same scenario for animals -> unruly triggers the need for a migration 
   which is then moved to unruly
   - 
https://bitbucket.org/emma_nuelle/migrate_othe_app_sample/commits/ef14b382eccf463548c25ad19127f8fea9154f54
 
   : a "conflicting" migration has been created by the maintainer of animals. 
   When I say conflicting, it means that it's a migration on the same field as 
   the one created by unruly, actually Django runs both migrations without any 
   trouble (no --merge required). The actual troubles are:
   - the migrations are not run in the same order depending whether the 
  migrations are run on an empty db or on a pre-existing db.
  - in the case of running the migration on a pre-existing db, the db 
  field and the Django field are different
   - 
https://bitbucket.org/emma_nuelle/migrate_othe_app_sample/commits/e35f1f4ca4c3e1ddeb6304fe97c43003bf7c2f59
 
   : solution to both problems created by the previous commit -> create a 
   migration manually which will update the db field and will make sure the 
   order in which the previous migrations are run is not important
   
During the creation of the described process, the only time I had to 
message from Django telling me to run --merge was because I had made a 
mistake in the order of the steps of "pretending to be the maintainer of 
the other app".
I believe the second scenario is probably an edge-case not representative 
of what might happen with migrations created by modeltranslations or app 
extensions (as long as they are created by sensible people).

Emma

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

Django oscar core apps confilicts with my local apps

[Kishan Mehta]

 

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',
'django.contrib.staticfiles',
# local apps
'content',
'usermgmt',
'resources',
'assessment',
'analytics',
'utils',
# 'notify',
# Auth related apps
'oauth2_provider',
'social.apps.django_app.default',
'rest_framework_social_oauth2',
# rest
'rest_framework',
'djoser',
# misc - third party
'reversion',
'corsheaders',
'notifications',
#oscar
'oscarapi',



] + get_core_apps()


While running server : 



Traceback (most recent call last):
 File "manage.py", line 10, in 
execute_from_command_line(sys.argv)
 File 
"/home/rss-20/.virtualenvs/kishan_pal/local/lib/python3.4/site-packages/django/core/management/__init__.py",
 line 338, in execute_from_command_line
utility.execute()
File 
"/home/rss-20/.virtualenvs/kishan_pal/local/lib/python3.4/site-packages/django/core/management/__init__.py",
 line 312, in execute
django.setup()
File 
"/home/rss-20/.virtualenvs/kishan_pal/local/lib/python3.4/site-packages/django/__init__.py",
 line 18, in setup
apps.populate(settings.INSTALLED_APPS)
File 
"/home/rss-20/.virtualenvs/kishan_pal/local/lib/python3.4/site-packages/django/apps/registry.py",
 line 89, in populate
"duplicates: %s" % app_config.label)
 django.core.exceptions.ImproperlyConfigured: Application labels aren't unique, 
duplicates: analytics



Aparently analystics is conflicting with the analytics in get_core_apps().


Is there any way to resolve this ?

-- 
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/f949c181-3e6a-4ec5-9fda-f5e1b9b8f1a4%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Django ORM query syntax enhancement

[Alexey Zankevich]

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:
>
> Expressions have built in support for ordering with asc or desc, see here: 
> https://docs.djangoproject.com/en/1.8/ref/models/expressions/#django.db.models.Expression.asc
>
> Meaning that -F() is never ambiguous, which is the main reason we went for 
> the F().desc() API rather than using the minus sign as an indicator of 
> ordering.
>
> To use the `P` example in an order by statement:
>
> Model.objects.order_by(P.related.date_field().desc())
>
> I've "called" date_field here, but that's just assuming an API. As long as 
> an expression is being returned, you can call `desc` on it.
>
> What some other ORMs do is reference fields directly on the model, though 
> I'm not sure I like the verboseness (but it gives you safety):
>
> Model.objects.order_by(Model.related.date_field.desc())
>
> The extra `Model` is annoying, but it does mean that you can actually look 
> up fields as you go rather than just crafting an `F()` that is eventually 
> resolved into the `Col()`. This would also allow us to return expressions 
> directly. Not sure how or if this API would work with the current 
> metaclasses though.
>
> For what it's worth, the names `TreePath` and `FieldTree` are too low 
> level for a public facing API that is supposed to make it easier/safer to 
> craft field paths. One letter class names are also a bad design in general, 
> so we'd need something half way between both if going for a new class.
>
>
> On Tuesday, 25 August 2015 04:13:32 UTC+10, Alexey Zankevich wrote:
>
> Hey Josh,
>
> Here is the current state of F support by different functions:
>
> * annotations (Count, Sum etc) - work
> * order_by - works partially (only asc order supported)
> * select_related, prefetch_related - don't work
>
> So, F is not a universal interface for getting paths right now. Also, 
> there is another problem with F - it overloads python operators already, so 
> if we overload unary operation "-F", it will confuse users as in one case 
> it will return CombinedExpression (ex. 0-F('fieldname')), in the other - 
> OrderBy (ex. -F('fieldname')).
> Since F originally designed to describe arithmetic upon fields during 
> filtering, it will not be a perfect match to denote query paths.
> As for accepting callable as a query path factory, I don't think it's a 
> perfect match as well, as callable interface is too general, at least to be 
> an unnamed argument.
> For example, fields.CharField(default=callable) is a clear approach, as 
> it's obvious what was implied. 
> ModelClass.objects.all().order_by(callable) - still clear, but 
> YearGte(callable, 40) isn't (since I'm talking about general interface to 
> specify query paths in the whole project).
> So, I suggest a separate class for that purposes, and it doesn't 
> necessarily need to have short name like "P". Even better if it has 
> meaningful name like "TreePath" or "FieldTree".
>
>
> On Friday, August 21, 2015 at 4:26:34 AM UTC+3, Josh Smeaton wrote:
>
> Most expressions already support strings, and most that support strings 
> expect them to be field_paths that can be wrapped in F() expressions. So 
> you have two options really, without built in support from other 
> expressions.
>
> 1. P.field.other.some_field() returns an F()
> 2. P.field.other.some_field() returns a str that will be internally 
> wrapped in an F().
>
> The callable part of your syntax is just something I'm suggesting as an 
> option. The requirement is that a string or F() be returned in some way 
> though. I'm also using "P." as a stand-in as you used previously.
>
> Supporting callables is an interesting idea, and I don't think that'll 
> cause issues with existing expressions. The callable must return an 
> expression though. If you wanted to write a patch to support callables, I'd 
> be onboard to review ASAP.
>
> Cheers
>
> On Friday, 21 August 2015 00:16:45 UTC+10, Alexey Zankevich wrote:
>
> What about the idea to add interface to specify paths with special class 
> or callable?
>
>
> On Wednesday, August 19, 2015 at 10:49:07 AM UTC+3, Josh Smeaton wrote:
>
> If I finish the patch in time (I think I have about a month left), then 
> it'll be included in 1.9. Review and comments on the PR will go a long way 
> to helping me tidy it up sooner rather than later, so please feel free to 
> review.
>
> Regards,
>
> On Wednesday, 19 August 2015 04:55:21 UTC+10, Alexey Zankevich wrote:
>
> Once Josh completes this patch https://github.com/django/django/pull/5090
> (.filter method accepting class-based lookups and transforms), it will be
> almost everything required by third-party apps. Is it going to be a part of
> Django 1.9, by the way?
>
> Additionally, for pure flexibility, next method and classes 

Re: Ability to migrate other applications

[Andrew Godwin]

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 throw a sample application today and try to reproduce the problem and
> see how it can be fixed/worked around. And write the appropriate tests.
>
>
That would be great - I've not actually tried it, so you're ahead of me
there, just trying to think of things that might muck it up!

I don't think it's too onerous to ask people to make merge migrations (as
Shai says), or to say you need to manually jiggle round dependencies if you
start using migrations like this, just want to work out what our options
are in this department.

I'm generally not very pro having apps mess with other apps' migrations -
because down that path madness lies, at least in some form - but I've also
come to accept that in larger projects it becomes a necessity, be it
modeltranslations (which I also disagree with the approach of), or apps
that encourage extension with models, etc. I still think Django should make
it quite hard to do this and screamingly obvious that you're going down a
dark path, but at the same time we should at least have it be possible.

Andrew

-- 
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/CAFwN1upGRs_W-6bPkzgV7PvBUyia8%3D4sm_hbmX8-E1ynDpRNPw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Ability to migrate other applications

[Shai Berger]

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
> dependencies, because say you made a third-party migration that depends on
> app_a.0003, and then they ship a new version that has app_a.0004, then
> suddenly app_a.0003 has two different children and the migration solver is
> going to really hate you.
> 

It's not going to hate her very badly, it will just ask her to add an empty 
"merge" migration. If the feature is supported, that migration will be added 
in the the external folder, and all will work fine. I still don't like the 
idea.

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).

Shai.

Re: Okay to use form field labels in admin history?

[Claude Paroz]

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 
> 
>
> One consideration is that the messages are generated/stored in the current 
> language so this could increase confusion in multilingual environments 
> until this issue is addressed:
> https://code.djangoproject.com/ticket/21113
>
> I'm not sure if we should block the current pull request on that ticket or 
> not.
>

I think that the correct way would be to fix #21113 first. Having transated 
content in the database looks like a bad idea in the first place.

Claude

-- 
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/2a6dd4ea-27a5-4fc8-88a2-42f9cccd018a%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: A new setting for custom gettext domains?

[Claude Paroz]

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 
> separate PR?
>

When separate PRs are doable and have each self-contained and coherent 
changes, it's always preferred.

Claude

-- 
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/c402033c-9374-4761-8a93-b6cca92fc3b0%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.