Re: Proposal to add a flatten() to django.utils

[Markus Holtermann]

Hi David,

I think, I'm in support for a django.utilsflatten() function with the 
requirements / constraints you outlined below.

Cheers,

Markus

On Mon, Oct 17, 2022, at 8:31 AM, David Sanders wrote:
> Hi folks,
> 
> As part of PR 16175  there was 
> some discussion around flattening lists/tuples as part of the solution. I 
> proposed that if we create a flattening function that there'd be some benefit 
> in sharing that in django.utils for other components if needed.
> 
> I'd like to garner "approval" + any thoughts on the best way to write such a 
> function.
>  * I'm aware that django.db expressions have similar-ish flatten() methods
>  * The PR author, Ion Alberdi, has done some nice work in writing up 
> alternatives and measuring performance
>  * A generator based solution would be nice if it could finish walking early 
> if used with any()
>  * Opinions on maintainability (readability) vs performance would be great
>  * Ideally I think it would be great if someone with some experience with 
> performant Python could chime in
> Cheers,
> David
> 
> 
> -- 
> 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 view this discussion on the web visit 
> https://groups.google.com/d/msgid/django-developers/CADyZw-5iwZPtsuw4Z%3D8nP16K%3DnP-0EAD5wZ4WaNy40L5oYuzfw%40mail.gmail.com
>  
> .

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/a16146bd-41ba-4c8d-aabf-62825a782328%40betaapp.fastmail.com.

Re: Add ability to show the migration plan (#23359)

[Markus Holtermann]

I don't see any problem having them coexist. After all it's just a 
"call_command()" that I already implemented. I'd only need to remove the 
deprecation warning.

On Monday, November 3, 2014 8:41:28 PM UTC+1, Tim Graham wrote:
>
> If we went with a separate command, would there be any problem having 
> --list on both migrate and showmigrations. I feel like deprecating it off 
> of migrate will cause more complaints about needless deprecations.
>
> On Wednesday, October 29, 2014 9:28:51 PM UTC-4, Andrew Godwin wrote:
>>
>> This used to be called "graphmigrations" in South, so I'm +0 on moving it 
>> to showmigrations; I don't want migrate to gain any extra functionality. 
>> That said, I tried moving --list to something separate during the 1.7 phase 
>> but there were objections to people who liked it on migrate.
>>
>> I don't really mind which way you go, to be honest; both seem like 
>> sensible places. Other people might have stronger opinions.
>>
>> Andrew
>>
>> On Wed, Oct 29, 2014 at 4:44 PM, Markus Holtermann <
>> in...@markusholtermann.eu> wrote:
>>
>>> Hey folks,
>>>
>>> A few weeks ago I opened a ticket (
>>> https://code.djangoproject.com/ticket/23359) to add the ability to show 
>>> a migration plan similar as listing all migrations within a project 
>>> (manage.py migrate --list). After some discussions on IRC and on the first 
>>> pull request (https://github.com/django/django/pull/3116) we realized 
>>> that there might even be more use cases, e.g. to output all migration files 
>>> as a dot file to generate a graph (
>>> https://github.com/django/django/pull/3116#issuecomment-53565075). 
>>> That's when I opened a second pull request that moves the existing "--list" 
>>> and the new "--plan" option from the "migrate" command to a 
>>> "showmigrations" command.
>>>
>>> Any suggestions on which way I should follow, integrate in "manage.py 
>>> migrate" (pull request 3116: https://github.com/django/django/pull/3116) 
>>> or add a new dedicated command "manage.py showmigrations" (pull request 
>>> 3153: https://github.com/django/django/pull/3153)?
>>>
>>> /Markus
>>>
>>> -- 
>>> 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/f8bdabfc-f005-4e8e-b1d9-0b69dfdedd82%40googlegroups.com
>>>  
>>> <https://groups.google.com/d/msgid/django-developers/f8bdabfc-f005-4e8e-b1d9-0b69dfdedd82%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/a53816ba-18e7-4489-b8c2-17e855245b10%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Make deconstructible classes forwards compatible

[Markus Holtermann]

Hi all,

As of now (Django 1.7.x and master) the migration writer serializes classes 
like the CreateModel operation with kwargs and not args. Which is the right way 
to do. However, as soon as Django changes some of these operations' constructor 
signatures (as I plan to do in https://code.djangoproject.com/ticket/23822) 
newly created migration files become backwards incompatible for 3rd party apps.

As a concrete example: CreateModel will get a "managers" argument in 1.8 (if my 
pull request will be accepted). Hence all migration files created with Django 
1.8 will contain a managers argument as well. Third party apps that want to 
provide compatibility for 1.7 and 1.8 will have a problem as managers is an 
unknown kwarg to CreateModel in 1.7.

I therefore propose to add **kwargs to all operations and would like that to be 
backported to 1.7 although its neither a bug nor security fix.

I haven't looked into other classes that are serialized by the migration writer 
if they would profit from the same patch, but from my perspective model fields 
don't need that change as their signature didn't change over "a decade".

Another possible problem I want to address but that I haven't looked into yet, 
is the serialization of args in general. I think having **kwargs for every 
deconstructible class and always serialize with kwargs and not having any args 
in the migration classes will prevent problems in the future, too.

Markus

-- 
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/E1XrnQg-0003J4-TT%40smtprelay01.ispgateway.de.
For more options, visit https://groups.google.com/d/optout.

Re: Make deconstructible classes forwards compatible

[Markus Holtermann]

Hey Carl,

On Friday, November 21, 2014 7:57:47 PM UTC+1, Carl Meyer wrote:
>
> Hi Markus, 
>
> On 11/21/2014 05:35 AM, Markus Holtermann wrote: 
> > As of now (Django 1.7.x and master) the migration writer serializes 
> > classes like the CreateModel operation with kwargs and not args. 
> > Which is the right way to do. However, as soon as Django changes some 
> > of these operations' constructor signatures (as I plan to do in 
> > https://code.djangoproject.com/ticket/23822) newly created migration 
> > files become backwards incompatible for 3rd party apps. 
> > 
> > As a concrete example: CreateModel will get a "managers" argument in 
> > 1.8 (if my pull request will be accepted). Hence all migration files 
> > created with Django 1.8 will contain a managers argument as well. 
> > Third party apps that want to provide compatibility for 1.7 and 1.8 
> > will have a problem as managers is an unknown kwarg to CreateModel in 
> > 1.7. 
> > 
> > I therefore propose to add **kwargs to all operations and would like 
> > that to be backported to 1.7 although its neither a bug nor security 
> > fix. 
>
> This makes sense to me. 
>

Thanks, I opened a ticket (https://code.djangoproject.com/ticket/23892) and 
added a pull-request (https://github.com/django/django/pull/3602)
 

> > I haven't looked into other classes that are serialized by the 
> > migration writer if they would profit from the same patch, but from 
> > my perspective model fields don't need that change as their signature 
> > didn't change over "a decade". 
> > 
> > Another possible problem I want to address but that I haven't looked 
> > into yet, is the serialization of args in general. I think having 
> > **kwargs for every deconstructible class and always serialize with 
> > kwargs and not having any args in the migration classes will prevent 
> > problems in the future, too. 
>
> I'm not sure how you're proposing to address this? It seems like it's up 
> to the implementor of `deconstruct()` for any particular class to decide 
> which things to record as args and which as kwargs, and to take into 
> account the backwards-compatibility considerations. It's not possible in 
> the general case to "always serialize with kwargs", since some objects 
> might accept some things only via `*args`. 
>
> If you just mean looking through the implementations of `deconstruct()` 
> in Django itself and using more kwargs and fewer args there, I think 
> that's a good idea. 
>

Yes, that's my idea. To keep track of the issue I opened 
https://code.djangoproject.com/ticket/23894.

I went through the code and from what I I've seen so far except for the 
PostgreSQL ArrayField and the migration operations all classes having an 
explicit deconstruct() method are using kwargs already. Those classes 
relying on the deconstructible decorator fall back to to whatever way they 
are used due to the underlying argument catching. But that should be fine. 
I we realize at some point that the positional arguments are bad there we 
can still make the deconstructible decorator more intelligent to merge the 
positional argument into keyword arguments.

Markus

-- 
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/0e3d5c01-0fe0-40b3-a02c-6fa9c87bed0a%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Infinite loop in migration code

[Markus Holtermann]

Hey Luke,

It would be interesting to see why A.1 and B.1 depend on each other. If 
there are e.g. FK constraints pointing to models in the other app the 
autodetector should end up with e.g. A.1 <-- B.1 <-- B.2 <-- A.2 (or 
optimized A.1 <-- B.1 <-- A.2), in which case you wouldn't end up with a 
cycle. C.1 would then depend on B.2 (B.1 respectively in the optimized 
graph).

/Markus

On Tuesday, November 25, 2014 4:49:22 PM UTC+1, Luke Plant wrote:
>
>
> I came across a bug with an infinite loop in migration dependency 
> searching code. This is fixed here: 
>
>
> https://github.com/django/django/commit/ff3d746e8d8e8fbe6de287bd0f4c3a9fa23c18dc
>  
>
> (another person reviewing it would be good, though I think it is correct). 
>
> My question is, should we backport this to 1.7.x? For me, the bug 
> manifested itself with migrations that were automatically created by 
> Django itself, in a project with apps A, B, and C: 
>
> App B depends on app A 
> App A depends on app B (it didn't initially, but does now) 
> App C depends on one/both of them. 
>
> After doing makemigrations for A and B, makemigrations for C then went 
> into an infinite loop. 
>
> So this is not a really obscure case, and could affect a fair number of 
> people attempting to upgrade to Django 1.7, as I was. 
>
> Regards, 
>
> Luke 
>
>
> -- 
> "We may not return the affection of those who like us, but we 
> always respect their good judgement." -- Libbie Fudim 
>
> Luke Plant || http://lukeplant.me.uk/ 
>

-- 
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/5e547550-1002-4a6b-82f0-a8dc7e3ed2b0%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Infinite loop in migration code

[Markus Holtermann]

Can you open a ticket with your models so the issue doesn't get lost. I'm 
happy to work on it.

Although it's somewhat uncommon, people normally have the through model in 
the app that has the m2m field (why don't you define it on the other 
model?) this is still something that shouldn't happen.

/Markus

On Wednesday, November 26, 2014 8:54:55 AM UTC+1, Luke Plant wrote:
>
> On 25/11/14 16:23, Markus Holtermann wrote: 
> > Hey Luke, 
> > 
> > It would be interesting to see why A.1 and B.1 depend on each other. If 
> > there are e.g. FK constraints pointing to models in the other app the 
> > autodetector should end up with e.g. A.1 <-- B.1 <-- B.2 <-- A.2 (or 
> > optimized A.1 <-- B.1 <-- A.2), in which case you wouldn't end up with a 
> > cycle. C.1 would then depend on B.2 (B.1 respectively in the optimized 
> > graph). 
>
> I didn't realise the autodetector could handle that. Looking more 
> closely, it looks like I have more of an edge case: 
>
> App B has a model with a FK to a model in app A 
>
> App A has a model with a ManyToMany field 'through' a model in app B. 
> (It's actually added that way for the sake of the admin for the models 
> in app A). 
>
> So it isn't the straight-forward A has FK to B. It might not be worth 
> fixing the autodetector for this, as fixing the migrations is relatively 
> easy. But I think fixing the infinite loop is another matter, and I'll 
> go ahead and backport that. 
>
> Thanks for the input, 
>
> Luke 
>
>
> -- 
> "We may not return the affection of those who like us, but we 
> always respect their good judgement." -- Libbie Fudim 
>
> Luke Plant || http://lukeplant.me.uk/ 
>

-- 
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/f2924e77-7604-4632-a7c1-1920a3bfb4d0%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: does django-admin need a man page?

[Markus Holtermann]

On Wednesday, November 26, 2014 7:46:16 AM UTC+1, Aymeric Augustin wrote:
>
> Le 26 nov. 2014 à 01:51, Nick Phillips  > a écrit : 
> > 
> > I'd suggest considering implementing 
> > something to generate a man page from whatever you wish the "canonical" 
> > source of the information to be. 
>
> The canonical source of information is: 
> https://docs.djangoproject.com/en/dev/ref/django-admin/ 
>
> Does a rst-->man conversion tool exist? 
>

Yes, rst2man.py is part of docutils. And Sphinx even has a man builder. 
Inside the docs directory run "make man". The generated man page is 4MB 
though, and contains the _entire_ documentation, not only the 
django-admin.py command. But there should be some way to work around that.
 
/Markus

-- 
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/e82f9bfd-b867-44cb-b3f1-4f7a223faf2a%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Infinite loop in migration code

[Markus Holtermann]

Hey Luke,

I cannot reproduce your problem on neither master nor stable/1.7.x. When I 
run "python manage.py makemigrations camps" the migrations for the 
"officers" app are also generated (as I expect it). "testapp" is your 
"camps" app, "otherapp" is your "officers" app: 
https://gist.github.com/MarkusH/d84618db929fd6fcdb9f

The dependencies look fine to me, and migrating works like a charm. I also 
tried both the string representation 'auth.User' and importing d.c.a.m.User 
and using the class reference in the FK fields, but that doesn't make any 
difference.

If you can reproduce the issue, could you please push a sample project to 
GitHub. I'm happy to look into it then.

/Markus

On Thursday, November 27, 2014 5:20:52 PM UTC+1, Luke Plant wrote:
>
> Hi Markus, 
>
>
> It was basically this: 
>
> == app camps == 
>
> class Camp: 
>
>   invited_officers = M2M(auth.User, through='officers.Invitation') 
>
>
> == app officers == 
>
> class Invitation: 
>   timestamp = models.DateTimeField(default=datetime.now) 
>   camp = FK(camps.Camp) 
>   user = FK(auth.User) 
>
>
> = 
>
> I ran makemigrations for 'camps', then 'officers', and the generated 
> migrations ended up depending on each other. 
>
> Hopefully that's enough, let me know if that doesn't reproduce it. 
> Sorry, don't have time to put it together more formally. 
>
> Thanks, 
>
> Luke 
>
>
> On 26/11/14 13:08, Markus Holtermann wrote: 
> > Can you open a ticket with your models so the issue doesn't get lost. 
> > I'm happy to work on it. 
> > 
> > Although it's somewhat uncommon, people normally have the through model 
> > in the app that has the m2m field (why don't you define it on the other 
> > model?) this is still something that shouldn't happen. 
> > 
> > /Markus 
> > 
> > On Wednesday, November 26, 2014 8:54:55 AM UTC+1, Luke Plant wrote: 
> > 
> > On 25/11/14 16:23, Markus Holtermann wrote: 
> > > Hey Luke, 
> > > 
> > > It would be interesting to see why A.1 and B.1 depend on each 
> > other. If 
> > > there are e.g. FK constraints pointing to models in the other app 
> the 
> > > autodetector should end up with e.g. A.1 <-- B.1 <-- B.2 <-- A.2 
> (or 
> > > optimized A.1 <-- B.1 <-- A.2), in which case you wouldn't end up 
> > with a 
> > > cycle. C.1 would then depend on B.2 (B.1 respectively in the 
> > optimized 
> > > graph). 
> > 
> > I didn't realise the autodetector could handle that. Looking more 
> > closely, it looks like I have more of an edge case: 
> > 
> > App B has a model with a FK to a model in app A 
> > 
> > App A has a model with a ManyToMany field 'through' a model in app 
> B. 
> > (It's actually added that way for the sake of the admin for the 
> models 
> > in app A). 
> > 
> > So it isn't the straight-forward A has FK to B. It might not be 
> worth 
> > fixing the autodetector for this, as fixing the migrations is 
> > relatively 
> > easy. But I think fixing the infinite loop is another matter, and 
> I'll 
> > go ahead and backport that. 
> > 
> > Thanks for the input, 
> > 
> > Luke 
> > 
> > 
> > -- 
> > "We may not return the affection of those who like us, but we 
> > always respect their good judgement." -- Libbie Fudim 
> > 
> > Luke Plant || http://lukeplant.me.uk/ 
>
>
> -- 
> "In your presence there is fullness of joy; at your right hand are 
> pleasures forevermore" Psalm 16:11 
>
> Luke Plant || http://lukeplant.me.uk/ 
>

-- 
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/83263507-d328-4b6e-95d6-e8a2e9d557f6%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: DB Migrations: Proposed fix for "Index name collisions after objects are renamed then re-created"

[Markus Holtermann]

Hey folks,

I don't like the idea of expected failures either.

Given the fact that at one point user defined indexes are going to be 
introduced, I would consider to delay this issue for now until the DEP has 
been accepted and is (being) implemented. At that point we know what the 
underlying API in e.g. the schema editor is and how we are generating the 
indexes in migrations. We might end up with AddIndex, AlterIndex and 
DeleteIndex operations where CreateModel etc don't know about the index.

Introducing some - in any way hacky-ish - "solution" to prevent duplicate 
index names would probably be deprecated as soon as custom indexes are 
implemented. That said, touching the migration operations for 1.8 (LTS) in 
a way that we are not sure yet is are going to stay, and later introducing 
a new API, seems a bit odd and complicated in terms of backwards 
compatibility from 1.9? where indexes are introduced.

/Markus

On Monday, December 1, 2014 6:35:17 PM UTC+1, Tim Graham wrote:
>
> I'm not in favor of merging expectedFailure tests:
> * It adds the overhead of time running tests that we know aren't expected 
> to work.
> * It's more code to maintain (might go stale in the meantime anyway).
> * An issue might be obsoleted (via deprecation, etc.) at some point.
> * When viewing commit history, it seems clearer to add tests when fixing 
> an issue rather than removing a decorator on a test (the contents of the 
> test won't be easily viewable in the latter case).
>
> We currently have < 10 tests marked as such in the test suite now. I'd 
> like to audit them to check their state. Here's a ticket if anyone wants to 
> help with that: https://code.djangoproject.com/ticket/23943
>
> On Monday, December 1, 2014 12:18:31 PM UTC-5, Carl Meyer wrote:
>>
>> On 11/30/2014 05:54 AM, tomv wrote: 
>> > It's important to note that right now, index names are not re-creatable 
>> in 
>> > retrospect. They rely on the names of models and fields, that are free 
>> to 
>> > be renamed. So a complete rethink will be needed if introspection can 
>> no 
>> > longer be used for user-specified types of indexes. For example, maybe 
>> the 
>> > user should choose the name, which they should make unique at the app 
>> > level? Or if not, Django will need to either keep a record of the 
>> generated 
>> > index name somewhere, or start renaming indexes to keep them up-to-date 
>> > with the components in their names. 
>>
>> I think one way or another with the indexes DEP we will need to surface 
>> the name of an index as an explicit part of its deconstructed 
>> specification (just like with fields, models, etc). This implies 
>> probably letting the user pick an explicit name if they want. We could 
>> also keep the option of using an autogenerated default name, but in that 
>> case migrations should notice if that autogenerated name changes and 
>> generate an index-name-change operation. 
>>
>> > What's the best way to proceed with the index name collision ticket 
>> #23577 
>> >  at this point then? I 
>> can: 
>> > 
>> >1. re-write my "use migration names in index names" branch 
>> ><
>> https://github.com/tomviner/django/compare/ticket_23577_with_poc_migration_name_fix>
>>  
>>
>> >to allow index suffix names passed from migration operations? 
>>
>> What about having the entire index name explicitly passed from the 
>> operation in migrations (even if for now its always autogenerated 
>> there)? That seems like maybe a step towards where I think we'll 
>> eventually need to be. (But take with a grain of salt, you've been in 
>> this code and I haven't). 
>>
>> >2. or declare there's no consensus on the solution / we'll wait for 
>> >Mark's index DEP - in which case, can I submit my tests 
>> > 
>> as 
>> >xfails? 
>>
>> Hmm, that's an interesting idea. It's not something we've generally done 
>> in the past, but it might be better than just letting the tests bit-rot 
>> as an un-merged PR, later probably needing to be rebased. I'm curious 
>> what others think of the idea of actually merging xfail tests for 
>> unfixed bugs? 
>>
>> 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/f54f7b38-f1d1-411d-801f-187c7425346d%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Adding model managers to migrations

[Markus Holtermann]

Ticket: https://code.djangoproject.com/ticket/23822
Pull Request: https://github.com/django/django/pull/3687

Hey folks,

As of now migrations don't expose the model managers to models. Thus it is 
"impossible" to use e.g. `create_superuser` in a `RunPython` operation. I 
opened ticket #23822 to keep track of that issue. I propose a solution as 
implemented in pull request 3687: managers get an optional class attribute 
`use_in_migrations` that, if True, will mark that manager to be added to 
migrations by the migration framework. Managers that are part of migrations 
need to stay around for as long as a migration references the managers. 
This is the same as with custom model fields or functions passed to field 
attributes (e.g. `upload_to`).

To keep track of the ordering of the managers (and know which one is really 
the default), I merged the `Model._meta.abstract_managers` and 
`.concrete_managers` into a single list and added properties to return the 
respective subsets instead.

The `managers` attribute on `CreateModel` will be empty without enabling at 
lease one manager. The normal manager (`models.Manager`) will (almost) 
never be serialized. Except for the situation where a model's default 
manager is a manager without migration support, but a custom manager is. In 
that case a default manager `objects = models.Manager()` will be added 
explicitly to prevent the non-default manager to become a default manager.

I added migration support for all contrib managers (where appropriate), e.g 
`UserManager` instead of `BaseUserManager`.

I'd like to get a thorough review before merging, especially regarding the 
`ModelState.render()` and `from_model()` functions. I think there are some 
improvements possible I haven't though about.

Thanks

/Markus

-- 
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/fe360009-39c3-4914-aa91-604f32461411%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Bypassing 1.7+ migrations

[Markus Holtermann]

Hey Marcin, Andrew,

setting manager=False wouldn't work either, as the migrations for those 
models still need to exist. I probably have references to them which makes 
them a requirement for FKs in migrations. Unmanaged models behave exactly 
the same as managed models in migrations, with one exception: the database 
operations aren't run.

/Markus

On Tuesday, December 16, 2014 1:34:17 PM UTC+1, Andrew Godwin wrote:
>
> Hi Marcin,
>
> If you're using an external tool to manage schemas of models, just set 
> managed=False on the models and Django will stop trying to change their 
> schemas (including stopping making migrations for them).
>
> Andrew
>
> On Tue, Dec 16, 2014 at 1:11 AM, Marcin Nowak  > wrote:
>>
>> Hello!
>>
>> I'm using Django as a part of bigger stack where I'm using external tool 
>> to manage database migrations.
>> After migration to Django 1.7 I'm encouraged at every runserver command 
>> to execute some migrations, which may blow my databases.
>>
>> I want to bypass Django migrations to prevent any schema modification. I 
>> can bypass migrate*  commands by overriding them in my custom app, but this 
>> is a little tricky and does not cover all cases. Using managed=False is not 
>> a solution, because none of reusable apps have models defined as unmanaged 
>> (same for django.contrib, especially auth and sessions).
>> That's why I need to bypass migrations globally.
>>
>> Have you ever considered possibility to allow disabling it? Maybe via 
>> some setting to use kind a DummyMigrationExecutor instead of 
>> MigrationExecutor? 
>>
>> 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-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/a27293a1-4212-4a2a-ae44-4720fc674162%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/f982778d-eb79-4c74-921c-2028d07138f2%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: #23996 Allow AlterOrderWithRespectTo to order existing data

[Markus Holtermann]

Hi Mike,

Thanks for grabbing it. I'd suggest to wait for the patch for #23983 being 
merged and than work on the updated master branch. From my point of view, 
the pull-request shouldn't add this new feature, as it would be backported 
to 1.7 which isn't covered by the backporting guidelines. Thus it'd be a 
new feature in 1.8

I would also wait for a +1 from a core dev or the technical board to start 
working on it.

/Markus

On Tuesday, December 16, 2014 2:17:42 PM UTC+1, mha...@ualberta.ca wrote:
>
> Hello all,
>
> I just grabbed this ticket, but then I noticed in pull request #3735 that 
> we don't have a consensus as to whether this feature should be added. Since 
> I'm new around here, I'd like to ask everyone's opinion on whether we 
> should move forward on this. I can implement it within a few days, and it 
> would give me a good chance to poke around the migrations framework (last 
> time I used Django, migrations were still handled by South).
>
> Thanks,
> Mike
>

-- 
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/b6ac63ac-bfbb-412c-bdd9-63c5bff3b119%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Bypassing 1.7+ migrations

[Markus Holtermann]

Hey Shai,

manage=False won't gain you anything, since those models will still show
up in migrations, because they need to be able to be referenced by
managed models. The migration database operations are noops though.

/Markus

On Thu, Dec 18, 2014 at 06:08:52AM +0200, Shai Berger wrote:

FWIW, the approach I would go for is to try to monkeypatch
managed=False into the base model Meta.

Shai.

On Tuesday 16 December 2014 14:49:25 Andrew Godwin wrote:

Hi Marcin,

You can't bypass migrations as much as you can't bypass syncdb; that is,
the commands are separate and you can choose not to run them (or just
delete the migration files). As far as I can tell your only issue is the
runserver warning that you have unmigrated changes, which there's currently
no plan to be able to disable.

Also bear in mind that, by doing your own schema management for the contrib
apps, you're kind of implicitly forking the schema; Django 1.8 will ship
with some migrations for these apps, and you're going to have to make sure
you manage those yourself and keep the database in sync with the code
(though of course the release notes will mention this kind of thing).

If you want to stub out migration operations, you can just make a custom
database backend that inherits from the one you use and define a new
SchemaEditor subclass with an execute() function that does nothing; that
should accomplish what you want. Alternatively, you could wrap all
migration operations into the State side of SeparateDatabaseAndState, but
that's a bit cumbersome.

Andrew

On Tue, Dec 16, 2014 at 4:42 AM, Marcin Nowak 

wrote:
> Hi Andrew,
>
> Thanks for a reply. But as I've mentioned above I can't set managed=False
> on models delivered from external apps like django.contrib.auth,
> django.contrib.sessions, and many more. Forking them is not an option.
>
> I think that bypassing migrations should be possible via some setting.
> That's why I wrote to developers forum directly.
> Please think about that.
>
> Marcin
>
> On Tuesday, December 16, 2014 1:34:17 PM UTC+1, Andrew Godwin wrote:
>> Hi Marcin,
>>
>> If you're using an external tool to manage schemas of models, just set
>> managed=False on the models and Django will stop trying to change their
>> schemas (including stopping making migrations for them).
>>
>> Andrew
>>
>> On Tue, Dec 16, 2014 at 1:11 AM, Marcin Nowak 
>>
>> wrote:
>>> Hello!
>>>
>>> I'm using Django as a part of bigger stack where I'm using external
>>> tool to manage database migrations.
>>> After migration to Django 1.7 I'm encouraged at every runserver command
>>> to execute some migrations, which may blow my databases.
>>>
>>> I want to bypass Django migrations to prevent any schema modification.
>>> I can bypass migrate*  commands by overriding them in my custom app,
>>> but this is a little tricky and does not cover all cases. Using
>>> managed=False is not a solution, because none of reusable apps have
>>> models defined as unmanaged (same for django.contrib, especially auth
>>> and sessions).
>>> That's why I need to bypass migrations globally.
>>>
>>> Have you ever considered possibility to allow disabling it? Maybe via
>>> some setting to use kind a DummyMigrationExecutor instead of
>>> MigrationExecutor?
>>>
>>> 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-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/a27293a1-4212-4a2a-ae44-
>>> 4720fc674162%40googlegroups.com
>>> >> -ae44-4720fc674162%40googlegroups.com?utm_medium=email&utm_source=foote
>>> r> .
>>> 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/d8226a81-9dfe-4019-94
> ce-98beb6e1bf04%40googlegroups.com
>  94ce-98beb6e1bf04%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

Re: status of 1.8 release blockers

[Markus Holtermann]

Hey Tim,

thanks for the collection of tasks that have to be done for 1.8.

Especially wrt #23861 and #23891 I just realized that, since 1.8 is an LTS 
release, we'd need to support and that field (and related changes) until 
2018. That's Django 2.2/2.3 I guess. Considering the ideas that exists to 
tackle that problem, I'm almost certain the backporting overhead required 
for fixes is huge once the code is removed from the general releases. I'm 
not sure about #22340, though, but I wouldn't be surprised if that's the 
same. I don't think we should consider delaying the deprecation to 2.0 or 
later. From my perspective this has to be fixed and decided for 1.8. 
Otherwise we are going to make our life a living hell.

I'm happy to assist and answer questions, but I don't have the time to 
completely work out and write down a solution.

/Markus

On Saturday, December 20, 2014 8:40:33 PM UTC+1, Tim Graham wrote:
>
> As we approach the date for 1.8 alpha, I plan to send a weekly update on 
> the status of release blocking issues.
>
> We currently have 3 release blockers affecting master. You can use this 
> Trac filter to see them:
>
> https://code.djangoproject.com/query?status=assigned&status=new&version=master&severity=Release+blocker
>
> You can also see other tickets we are targeting for 1.8 with this filter. 
> This includes some of the remaining large features as well as a couple code 
> reorganizations we want to make closer to when cut the 1.8 branch to avoid 
> creating conflicts with the large features that are in progress.
>
> https://code.djangoproject.com/query?status=assigned&status=new&keywords=~1.8-alpha
>
> Here is a summary of where we stand with each release blocker:
>
> #23861 - 
>  Fields referenced in 
> migrations cannot be (re)moved, even if migrations have been squashed 
>  Owner: ?
> Status: We need someone to investigate a strategy for how we can deprecate 
> model fields while keeping them available in historical migrations. Any 
> takers? If we cannot complete this, I propose we bump the deprecation of 
> IPAddressField until the issue is solved.
>
> #22340 -  
>  Legacy Table Creation 
> Methods Not Properly Deprecated 
>  Owner: Claude
> Status: This issue is being discussed in the thread "Migrations in Django 
> 1.7 make unit testing models harder". In short, we likely to need to solve 
> the performance issues with migrations before we can proceed with the 
> deprecation. If we cannot, we'll likely have to delay the deprecation.
>
> #23271 - Makemessages can 
> corrupt existing .po files on Windows 
> 
> Owner: Ramiro
> Status: Ramiro said he would have some time to investigate the issue soon.
>

-- 
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/5abfe5b8-4f2a-4982-b97a-529c0cd2c9cb%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Delivering PR 3114 - The _meta refactor

[Markus Holtermann]

Hey folks,

On Monday, December 22, 2014 3:29:15 PM UTC+1, Aymeric Augustin wrote:
>
> Hi Russell,
>
> 2014-12-22 8:39 GMT+01:00 Russell Keith-Magee  >:
>
>> The question: Do we - 
>>
>> 1) Accept this particular internal specific naming of GFK as a quirk 
>> reflecting the limitations of contrib.admin
>>
>> 2) Try to nail down what a "virtual" field means, or find some 
>> alternative flag to identify what "GFK" is a proxy for in this case.
>>
>
> I'm in favour of (1) mostly because of the YAGNI principle. Defining 
> "virtual"  without a concrete use case sounds hard.
>

Exactly: (1) seems to be the better option
 

> The question: Do we:
>>
>> 1) Accept this as a backwards incompatible change.
>>
>> 2) Accept the inconsistency in the new API.
>>
>> 3) Find a pair of names other than model/related_model to represent the 
>> "subject/object" pair in fields
>>
>
> I'm also in favour of (1) because the point of a refactoring is to clean 
> up inconsistencies. We can say something in the release notes to help 
> people who have used the RelatedObject private API.
>

+1. Cleaning up the current "mess" and accepting backwards 
incompatibilities of an undocumented internal API.

/Markus 

-- 
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/5af0fd95-9363-4f72-98c2-810801d16366%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: status of 1.8 release blockers

[Markus Holtermann]

On Monday, December 29, 2014 10:40:06 AM UTC+1, Claude Paroz wrote:
>
> On Saturday, December 27, 2014 4:46:52 PM UTC+1, Tim Graham wrote:
>>
>> #23745 - Migrations migrate is slow 
>>  (new)
>> Owner: Claude
>> Status: Patch seems to need improvement so it doesn't cause a regression 
>> with swappable models.
>>
>
> Sorry, but I'm afraid you should remove my name as the owner at this stage.
>

I took a look at the PR and added a test case that passes on stable/1.7.x 
and master. If the PR is applied as-is it fails: 
https://github.com/MarkusH/django/commit/9bc0d669e1fec3d9b3886ecf0c44bbf77b25ef6d
 
. But I'd like to get a few more eyes on the test so we can make sure it 
correctly represents the issue described in the ticket.

I furthermore tried to fix the issue with the patch 
in 
https://github.com/MarkusH/django/commit/9651ceebfe5a27bf4a095098e92454766480d931
 
. Assuming the test above is correct, this might be a way to solve the 
issue.

/Markus

-- 
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/48518bb0-bf86-4485-adae-4ce3cded100e%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: QuerySet.as_manager doesn't offer a way to use_for_related_fields

[Markus Holtermann]

Hey Martin,

To solve the problem I can think of two reasonable solutions:

class MyManager(models.Manager.from_queryset(MyQuerySet)):
use_for_related_fields = True

or

class MyModel(models.Model):
objects = MyQuerySet.as_manager()
objects.use_for_related_fields = True

After all, as_manager() calls from_queryset() internally.

I don't think a class attribute on the QS class makes much sense since 
as_manager() would be the only place where it is used. An argument to 
as_manager() would make more sense to me, though I'm not convinced this is 
really that much of an improvement.

>From the two suggested solutions above, I'd tend to use the first one.

/Markus

On Wednesday, December 31, 2014 2:47:41 AM UTC+1, Martin Chase wrote:
>
> Hey all,
>
> I make extensive use of managers, and I was excited to start using 
> as_manager for my queryset/manager mashups, but it seems 
> use_for_related_fields isn't a part of as_manager's considerations. I can 
> think of two sensible implementations: pass an argument to as_manager(), or 
> honor a class attr of the same name on the queryset.
>
> Is this a reasonable improvement? Is one of those possible implementations 
> (or a completely different one) better?
>
> Regards,
> Martin Chase
>

-- 
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/a167e890-82e6-43e8-b504-0c8a09efd774%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Replace decimal prefix(kB) with binary prefix (KiB) for bytes

[Markus Holtermann]

Hey folks,

I saw that the Django docs currently use file size units kB, MB, etc.
that refer to a multiple of 1000 (1000, 100 bytes respectively --
https://docs.djangoproject.com/en/dev/ref/settings/#file-upload-max-memory-size
). But the numbers actually are to the power of 1024. To remedy
inconsistencies there are binary prefixes KiB (Kibibyte), MiB
(Mebibyte), etc. which refer to 1024 and 1048576 bytes respectively (
http://en.wikipedia.org/wiki/Binary_prefix )

The Python documentation itself changed the notation about 2 years ago (
http://bugs.python.org/issue17193 ) -- Thanks for the hint, Berker.

I therefore propose to change the notation to use the binary prefix.

I opened a ticket to track this proposal:
https://code.djangoproject.com/ticket/24140

Input and thoughts welcome :)

/Markus

-- 
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/54B45E6B.5080505%40markusholtermann.eu.
For more options, visit https://groups.google.com/d/optout.


signature.asc
Description: OpenPGP digital signature

Re: Keeping apps without migrations?

[Markus Holtermann]

Creating in-memory migrations for all apps that don't have migration
files seems to be an option to solve the dependency problem. This would
even allow apps without migrations to depend on those with migrations.

We have to consider though, that there are tens of apps and hundreds of
models in our own test suite, and generating all migrations during start
seems to be quite an expensive task. And I'm not even talking about the
migration optimizer which probably needs to get a lot smarter if we take
this road.

syncdb, which leaves a developer with a database scheme that cannot be
altered automatically, is something we should get rid of as soon as
possible, especially since Django has a out-of-the-box migration system.

/Markus

On Sun, Jan 18, 2015 at 01:50:14PM -0800, Andrew Godwin wrote:

My main argument for removing them entirely was the dependency issues
between apps with and without migrations. Having syncdb use SchemaEditor is
a big step and one I'm happy we've got to, but the only advantage of
keeping syncdb is for the test suite and I'd rather we approach that more
as "migrations made and run at runtime as a special case" rather than
"syncdb".

If nothing else, I'd like to see the end-developer-facing parts, like the
syncdb command itself, gone.

Andrew

On Sun, Jan 18, 2015 at 1:43 PM, Claude Paroz  wrote:


Tim recently did a fabulous job of removing deprecated code for the
future 1.9 on master. Thanks for that.

However, one thing he removed was support for apps without migrations.

https://github.com/django/django/commit/7e8cf74dc74539f40f4cea53c1e8bba82791fcb6

Considering that we have to keep internal support for Django's own test
suite anyway, I wonder if we should remove that support at all for
"normal" projects. I think one of Andrew's motivation was not to have to
keep two schema editing code bases. But now that the old syncdb also
uses the new schema editor, I think that this argument doesn't stand.

So what about keeping support for apps without migrations in the longer
term. Of course, the fact that those apps cannot depend on migrated apps
limits its use, but I think that for quick prototyping and initial
developement, migrations could be more of a hindrance. Would you see
major drawbacks with keeping this support?

Opinions welcome.

Claude
--
www.2xlibre.net


--
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/20150118221144.GA31780%40pyler.local.
For more options, visit https://groups.google.com/d/optout.


pgpRKu9huGEzV.pgp
Description: PGP signature

Re: Must a Django Database Support Migrations?

[Markus Holtermann]

Hey,

as soon as the MigrationRecorder is used there is a call to "ensure_schema" 
that forces the creation of the migration table. The runserver command 
(among others?) checks for unapplied migrations and thus creates the 
migration table.

/Markus

On Wednesday, January 21, 2015 at 12:36:47 AM UTC+1, Andrew Godwin wrote:
>
> Hi Ivan,
>
> I'm not sure what you're asking here - are you asking to have a way to not 
> have Django create the migrations recording table? I was under the 
> impression that it was only created when migrate was run (at least, that 
> was my original intention) so if you're managing your own schema just don't 
> run migrate. Is there something else that's not working right, or is that 
> being made too optimistically?
>
> Andrew
>
> On Tue, Jan 20, 2015 at 2:44 PM, Ivan VenOsdel  > wrote:
>
>> From Andrew: "The only extra thing it would achieve is not having Django 
>> record migrations in the django_migrations table"
>>
>> The Django Users thread on how to keep this table from being created 
>> seemed to result in the 'solution' being either to stay with 1.6 or comment 
>> the relevant lines in the Django code base. Is there really no other way?
>>
>> I love the new migrations facilities in Django 1.7 and was a contributor 
>> to the kickstarter but please keep in mind that many legacy DB projects are 
>> not avoiding migrations because they want to. IMO it's usually because they 
>> are forced to for some (usually political) reason where they don't have 
>> control over the schema. Forcing a perpetually empty django_migrations 
>> table pretty much locks out those users.
>>
>> I see that people are worried about encouraging the non-use of migrations 
>> but might I suggest following the Zen of Python and making migrations the 
>> "one obvious way to do it" and turning them off the not obvious way.
>>
>> Ivan
>>
>> On Wednesday, January 22, 2014 at 5:40:35 AM UTC-6, Andrew Godwin wrote:
>>>
>>> My thoughts in brief on this:
>>>
>>>  - Database backends don't support migrations - they support schema 
>>> alteration via SchemaEditor. This could be used separately from migrations 
>>> if something wants it, and is meant to be an API on its own, so the backend 
>>> is not the place to say if you want migrations or not.
>>>
>>>  - There is some merit to the ability to turn off migrations on a 
>>> per-backend basis, via a DATABASES setting, but bear in mind that routers 
>>> already let you do this (with the allow_migrate method). The only extra 
>>> thing it would achieve is not having Django record migrations in the 
>>> django_migrations table, but it also looks like it would be useful for 
>>> tests if you hadn't written that part yet.
>>>
>>>  - I feel like a DB backend should at least implement SchemaEditor even 
>>> if it returns NotImplementedError for most of the endpoints; even in the 
>>> weirdest relational system, you can still manage create/delete model 
>>> without too much difficulty.
>>>
>>>  - Bear in mind that the plan is to remove DatabaseCreation entirely in 
>>> favour of SchemaEditor in a few releases' time (and backends are more than 
>>> welcome to make DatabaseCreation use SchemaEditor behind the scenes if they 
>>> want), so at that point if you don't implement it the backend is only ever 
>>> good for querying, which to me feels like an incomplete backend.
>>>
>>>  - I'm not sure what the future of ./manage.py sqlall is, but it's going 
>>> to have to be ported to SchemaEditor in future anyway, so it's only useful 
>>> in the transition.
>>>
>>> Looking at the discussion, I think the best thing to do is:
>>>
>>>  - Make the schema and migrations test skip if 
>>> connection.schema_editor() raises a NotImplementedError (not too hard, we 
>>> can implement connection.has_schema_editor as a boolean to switch on)
>>>  - Provide some way to skip the "creating models" part of test setup, so 
>>> SchemaEditor is never needed during it
>>>
>>> I still think all the current third-party backends should be able to 
>>> provide a partial SchemaEditor implementation though, as at minimum they 
>>> all have the DatabaseCreation code in place to make new models. Bear in 
>>> mind that the ./manage.py sqlmigrate command lets you turn migrations into 
>>> SQL scripts to send to your DBA (and many DBAs appreciate having some SQL 
>>> they can work from - I know ours do), so having the ability to make that 
>>> SQL is useful even if Django never runs it.
>>>
>>> Andrew
>>>
>>>
>>> On Wed, Jan 22, 2014 at 10:10 AM, Shai Berger  
>>> wrote:
>>>
 On Wednesday 22 January 2014 16:26:50 Russell Keith-Magee wrote:
 > On Wed, Jan 22, 2014 at 3:59 PM, Shai Berger  
 wrote:
 > >
 > > B) Allow the test suite to run on an existing schema. The Oracle 
 backend
 > > already does this (badly) -- its six specific TEST_* parameters are
 > > awkwardly named, but allow you to say exactly which schema to use 
 for
 > > testing, and whether or not you want 

Usage of field cardinality flags in database schema backends

[Markus Holtermann]

Hey all,

Since Django 1.8 (currently in alpha state), model fields gained cardinality 
flags as part of the _meta refactoring. So, there is one_to_one, one_to_many, 
many_to_one and many_to_many. These flags are currently only used inside 
user-facing APIs such as forms and the admin.

Furthermore model fields have a get_internal_type() method that returns 
self.__class__.__name__ if they don't explicitly override that function (as 
many of the built-in fields do). This method is heavily used inside the 
backends.

Besides those two ways to "try" to figure out what Django has to do in a 
certain situation, the code uses e.g. isinstance(field.rel, ManyToManyRel) and 
isinstance(field, ManyToManyField) to check for many-to-many relationships.

This is quite confusing. At least to me. In 
https://github.com/django/django/commit/38c17871bb6dafd489367f6fe8bc56199223adb8
 I committed a patch that uses field.many_to_many in order to figure out if a 
certain column needs to be copied from one table to another (it doesn't if it's 
an m2m relation) when altering a table on SQLite.

However changing that to use get_internal_name() and keep existing code working 
is not trivial since neither ForeignKey nor ManyToManyField or OneToOneField 
have those methods defined. Thus fields inheriting from either of them need to 
explicitly define the method to return "ForeignKey", "ManyToManyField" or 
"OneToOneField". (The backport of that patch to 1.7 unfortunately breaks 
existing projects).

I have a pull request open to fix the issue on 1.7 related to m2m fields: 
https://github.com/django/django/pull/3998 .

However, I don't really like that repetitive pattern of checking for 
inheritance and get_internal_type(). I'm thinking about keeping the pattern in 
1.8 (and replacing the above checks with the one in the pull request) and 
accept https://github.com/django/django/pull/4002 for 1.9. Thus all projects 
and apps that rely on the class name of a related fields need to update their 
code and explicitly return the class name.

Thoughts and input highly welcome.

/Markus

-- 
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/b66842ee-62d6-43f2-a3df-838020cf60a2%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: discontinue shipping tests with contrib apps?

[Markus Holtermann]

I'm +1 on moving the contrib tests to tests/_tests/ .

The respective ticket on Trac is https://code.djangoproject.com/ticket/24293

/Markus

On Monday, February 9, 2015 at 4:09:47 PM UTC+1, Tim Graham wrote:
>
> I wonder if there is any need to continue to ship tests as part of contrib 
> apps? Currently the contributing docs say, "Tests for contrib apps go in 
> their respective directories under django/contrib, in a tests.py file. 
> You can split the tests over multiple modules by using a tests directory 
> in the normal Python way." but we are currently inconsistent (see below). 
> Shipping the tests in contrib means that end users may try to run them with 
> their own projects and this often leads to failures if their project's 
> settings do not match the settings that runtests.py expects. (e.g. #24299 
> asks for us to skip contrib tests that require an 'other' database 
> connection if a project doesn't have that). 
>
> apps with tests in tests/
> admin
> admin_docs
> postgres
> staticfiles
> syndication
>
> apps with tests in contrib/
> auth
> flatpages
> gis
> humanize
> messages
> redirects
> sessions
> sitemaps
> sites
>
> apps with tests in both locations
> contenttypes
>

-- 
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/da91fe85-66e9-4122-a4f7-8e99fce770f9%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: status of 1.8 release blockers

[Markus Holtermann]

Hey Tim,

Thanks for the update. Could you check if #24282 is fixed by my PR as well and 
assign it to me in case it is. The error message looks familiar to the one I 
commented on the PR. Thanks.

/Markus

On February 13, 2015 2:33:38 AM GMT+01:00, Tim Graham  
wrote:
>Status of release blockers:
>
>#24320  Unable to
>serialize 
>UUIDField when running dumpdata with JSON format 
>
>Status: I wrote a failing test and will try to write a patch tomorrow
>if no 
>one else takes a look first.
>
>#24289  Is usage of 
>many_to_one and one_to_many terms confusing for relation flags? 
>
>Status: We are waiting for feedback/confirmation from Anssi and Russ
>about 
>the direction to take here.
>
>#24225  KeyError when 
>migrating in 1.8a1/master@728b6fd (does not occur in 1.7.3) 
>
>#24264  foreign key
>constraint 
>error migrating integer pk to CharField 
>
>Status: Markus has a patch which addresses both issues. It's in good
>shape 
>and should be ready for commit soon.
>
>#24282  Cannot Modify
>Foreign 
>Keys Within Data Migrations
>
>Status: This is awaiting a test case to reproduce the issue (I'll 
>investigate tomorrow if no one else does).
>
>Here is the filter for 1.8 release blockers as well as issues tagged
>1.8 
>beta or 1.8 and thus are on my radar to make a decision on in the next 
>couple days:
>https://code.djangoproject.com/query?status=assigned&status=new&version=1.8alpha1&severity=Release+blocker&or&keywords=~1.8-beta&status=assigned&status=new&or&keywords=~1.8&status=assigned&status=new&col=id&col=summary&col=status&col=owner&col=type&col=component&col=changetime&desc=1&order=changetime
>
>On Wednesday, February 4, 2015 at 9:45:33 AM UTC-5, Tim Graham wrote:
>>
>> Reminder that the 1.8 beta release is scheduled for twelve days from
>now: 
>> Monday, February 16. 
>>
>> Please check this filter for remaining blockers for beta:
>>
>>
>>
>https://code.djangoproject.com/query?status=assigned&status=new&version=1.8alpha1&severity=Release+blocker&or&status=assigned&status=new&keywords=~1.8-beta&col=id&col=summary&col=status&col=owner&col=type&col=component&col=changetime&desc=1&order=changetime
>>
>> I'll follow up next week to ensure we have owners for any issues that
>
>> remain after the weekend.
>>
>> On Thursday, January 15, 2015 at 8:30:04 PM UTC-5, Tim Graham wrote:
>>>
>>> I think master is stabilizing and the number of unsolved regressions
>
>>> should be ~0 by tomorrow. I'd like to release the alpha around 2100
>UTC 
>>> tomorrow +/- ~4 hours depending on how things go with the remaining
>issues. 
>>> Let me know if there is anything you think needs to be in the alpha
>that 
>>> wouldn't meet this deadline.
>>>
>>> On Tuesday, January 13, 2015 at 1:50:26 AM UTC-5, Tino de Bruijn
>wrote:

 Congratulations! Looks like you've steadily moved it through.

 Tino

 On Tue, Jan 13, 2015 at 3:25 AM, Tim Graham 
>wrote:

> We did it -- all features are in or out for alpha. Please consider
>
> master frozen for new features until we cut the stable/1.8.x
>branch later 
> this week. Feel free to commit code cleanups and/or bug fixes
>until then.
>
>
> On Friday, January 9, 2015 at 1:14:02 PM UTC-5, Tim Graham wrote:
>>
>> Here is the fifth update with several days to go until alpha. I 
>> believe we are on track for a feature freeze at the end of day on
>Monday. 
>> Let's see how things go, but I'd like to cut the stable/1.8.x
>branch and 
>> issue the alpha release by the following Friday (a week from
>today).
>>
>> New blockers:
>>
>> #24075  - Can't
>migrate 
>> contenttypes and auth to zero 
>> 
>> Owner: Simon
>> Status: This is an existing issue on 1.7, but addressing it seems
>to 
>> require (or at least, would be a lot easier) with the proposed
>new feature 
>> of adding a "plan" argument to the post_migrate() signal. There
>is a patch 
>> in the works.
>>
>> Resolved since last time:
>>
>> #23861 - 
>>  Fields referenced
>in 
>> migrations cannot be (re)moved, even if migrations have been
>squashed 
>> 
>> Owner: Tim
>> Now: I polished and committed the patch for this.
>> Last time: I committed a patch for the second ticket and will
>polish 
>> the patch for the first issue.
>>
>> Most of the issues tagged "1.8-alp

Re: status of 1.8 release blockers

[Markus Holtermann]

Hey folks,

I looked into the issues #24225, #24264 and #24282 and have a working pull 
request ready for review: https://github.com/django/django/pull/4097

The essential change in the pull request is the way how the set of models 
that needs to be rerendered is constructed. Instead of naively only 
resolving one level of relations (Only rerender B and C if C changed: A --> 
B --> C) the new approach recursively checks for relational fields 
(forwards and reverse relations (e.g. ForeignKey and ManyToManyRel)) as 
well as inheritance.

This approach boils down to the following behavior:

If a completely standalone model (no incoming or outgoing relations and no 
subclasses and only a directed subclass of models.Model) changes, only this 
model will be rerendered, which is the best case scenario. If every model 
is somehow related (directly or through other models) to every other model, 
e.g. through the user model, changing one model from that set will require 
*all* models to be rerendered, which is the worst case scenario and results 
in the similar behavior as 1.7.

To get that pull request into the 1.8 beta I ask everybody to take a look 
and try it out on their projects. Especially if 1.8 alpha 1 didn't work for 
you.

Thanks

/Markus

On Saturday, December 20, 2014 at 8:40:33 PM UTC+1, Tim Graham wrote:
>
> As we approach the date for 1.8 alpha, I plan to send a weekly update on 
> the status of release blocking issues.
>
> We currently have 3 release blockers affecting master. You can use this 
> Trac filter to see them:
>
> https://code.djangoproject.com/query?status=assigned&status=new&version=master&severity=Release+blocker
>
> You can also see other tickets we are targeting for 1.8 with this filter. 
> This includes some of the remaining large features as well as a couple code 
> reorganizations we want to make closer to when cut the 1.8 branch to avoid 
> creating conflicts with the large features that are in progress.
>
> https://code.djangoproject.com/query?status=assigned&status=new&keywords=~1.8-alpha
>
> Here is a summary of where we stand with each release blocker:
>
> #23861 - 
>  Fields referenced in 
> migrations cannot be (re)moved, even if migrations have been squashed 
>  Owner: ?
> Status: We need someone to investigate a strategy for how we can deprecate 
> model fields while keeping them available in historical migrations. Any 
> takers? If we cannot complete this, I propose we bump the deprecation of 
> IPAddressField until the issue is solved.
>
> #22340 -  
>  Legacy Table Creation 
> Methods Not Properly Deprecated 
>  Owner: Claude
> Status: This issue is being discussed in the thread "Migrations in Django 
> 1.7 make unit testing models harder". In short, we likely to need to solve 
> the performance issues with migrations before we can proceed with the 
> deprecation. If we cannot, we'll likely have to delay the deprecation.
>
> #23271 - Makemessages can 
> corrupt existing .po files on Windows 
> 
> Owner: Ramiro
> Status: Ramiro said he would have some time to investigate the issue soon.
>

-- 
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/347cdd1d-bb4e-406e-bc85-f75f9c99ead5%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: status of 1.8 release blockers

[Markus Holtermann]

So, it turns out that #24291 (Migrations fail with unused swappable model) 
<https://code.djangoproject.com/ticket/24291> only occurs when a swapped 
out model doesn't define an explicit model manager. Since auth.User is the 
only model that is officially supported for "swappiness" and it defines an 
explicit UserManager this isn't really a problem in my opinion. Since the 
whole swappable model API is internal API anyway, I don't want to rule this 
issue a release blocker. If projects in the wild use the swappable model 
API they can get around the issue by adding `objects = models.Manager()` to 
that model.

Tim, Russ, thoughts 'bout that?

/Markus

On Tuesday, February 17, 2015 at 1:05:37 AM UTC+1, Tim Graham wrote:
>
> Here's the status on blockers. Given the work that remains, I don't 
> foresee the beta release happening earlier than Wednesday, but the next 
> update of this thread will be tomorrow.
>
> #24324 <https://code.djangoproject.com/ticket/24324> Crashes when project 
> path or path to Django install contains a non-ascii character 
> <https://code.djangoproject.com/ticket/24324>
> Owner: Tim
> Status: Patch needs review
>
>
> #24351 <https://code.djangoproject.com/ticket/24351>   RunPython/RunSQL 
> operations in contrib migrations and multi-db routers. 
> <https://code.djangoproject.com/ticket/24351>Owner: Loic
> Status: API design decision needed. Time permitting, Loic will write to 
> the mailing list on this tomorrow.
>
> #24328 <https://code.djangoproject.com/ticket/24328> The new 
> Options._get_fields() method needs to be cleaned up 
> <https://code.djangoproject.com/ticket/24328>
> Owner: Anssi
> Status: Anssi still reviewing the patch; decision may be needed on 
> backwards compatibility of get_fields().
>
> #24343 <https://code.djangoproject.com/ticket/24343> UUID foreign key 
> accessor returns inconsistent type 
> <https://code.djangoproject.com/ticket/24343>Owner: Marc/Josh/Shai
> Status: Josh working on cleaning up the patch. Review/feedback from Anssi 
> requested.
>
> #24291 
> <https://www.google.com/url?q=https%3A%2F%2Fcode.djangoproject.com%2Fticket%2F24291&sa=D&sntz=1&usg=AFQjCNFRo9Jwwoq-jqakfDLb4SIzKkWJ3g>
>  Migrations 
> fail with unused swappable model 
> <https://code.djangoproject.com/ticket/24291>
> Owner: Markus
> Status: Patch looks good to me; Markus to review & commit tomorrow.
>
> On Monday, February 16, 2015 at 11:12:46 AM UTC-5, Tim Graham wrote:
>>
>> There are still quite a few unresolved issues, so the beta release won't 
>> happen today. I'll send an update at the end of the day with the status of 
>> the remaining issues.
>>
>> On Friday, February 13, 2015 at 1:30:44 PM UTC-5, Markus Holtermann wrote:
>>>
>>> Hey folks,
>>>
>>> I looked into the issues #24225, #24264 and #24282 and have a working 
>>> pull request ready for review: 
>>> https://github.com/django/django/pull/4097
>>>
>>> The essential change in the pull request is the way how the set of 
>>> models that needs to be rerendered is constructed. Instead of naively only 
>>> resolving one level of relations (Only rerender B and C if C changed: A --> 
>>> B --> C) the new approach recursively checks for relational fields 
>>> (forwards and reverse relations (e.g. ForeignKey and ManyToManyRel)) as 
>>> well as inheritance.
>>>
>>> This approach boils down to the following behavior:
>>>
>>> If a completely standalone model (no incoming or outgoing relations and 
>>> no subclasses and only a directed subclass of models.Model) changes, only 
>>> this model will be rerendered, which is the best case scenario. If every 
>>> model is somehow related (directly or through other models) to every other 
>>> model, e.g. through the user model, changing one model from that set will 
>>> require *all* models to be rerendered, which is the worst case scenario 
>>> and results in the similar behavior as 1.7.
>>>
>>> To get that pull request into the 1.8 beta I ask everybody to take a 
>>> look and try it out on their projects. Especially if 1.8 alpha 1 didn't 
>>> work for you.
>>>
>>> Thanks
>>>
>>> /Markus
>>>
>>> On Saturday, December 20, 2014 at 8:40:33 PM UTC+1, Tim Graham wrote:
>>>>
>>>> As we approach the date for 1.8 alpha, I plan to send a weekly update 
>>>> on the status of release blocking issues.
>>>>
>>>> We currently have 3 release blockers affec

Re: Support for DATABASES['default'] = {}

[Markus Holtermann]

The question I'm asking myself right now: what is a "default" database in a 
multi database setup where "default" does not make sense at all? I can 
easily think of a case where I have multiple other databases used by other 
services where Django provides a dashboard. I don't see any of those 
databases being a "default".

That said, having an implicit default database that defaults to a dummy 
backend doesn't seem too bad. I'd rather see the docs updated in that 
regards and fix code that relies on "default" although giving an explicit 
database alias isn't complicated. "manage.py test" could get a --database 
option (if it doesn't have it already).

/Markus

On Tuesday, February 24, 2015 at 3:11:08 PM UTC+1, Marc Tamlyn wrote:
>
> I can't see why it is sensible to support an invalid database 
> configuration as the default. If you explicitly want the default to be a 
> dummy, you should configure that IMO.
>
> On 24 February 2015 at 14:04, Marten Kenbeek  > wrote:
>
>> Which one? :P This was more intended as a question than as a proposal.
>>
>> I personally prefer a documentation change and strict checking of 
>> `default` if and only if the database configuration is not empty. 
>> django.db.connection relies on the default connection, and third-party apps 
>> which (intentionally or unintentionally) do not support multi-db setups 
>> might be using that. I can't think of a scenario where it hurts to have a 
>> default database. I'm easily swayed on this matter, though. 
>>
>> On Tuesday, February 24, 2015 at 2:52:47 PM UTC+1, Marc Tamlyn wrote:
>>>
>>> In that case your proposal sounds perfectly reasonable.
>>>
>>> On 24 February 2015 at 13:47, Marten Kenbeek  wrote:
>>>
 In fact, DATABASES={} is a valid configuration and merely sets 
 'default' as a dummy backend. An exception is only explicitly raised if 
 you 
 supply a non-empty setting that does not include `default`. 

 On Tuesday, February 24, 2015 at 2:43:51 PM UTC+1, Marc Tamlyn wrote:
>
> It would seem more sensible to me to try to support DATABASES={}. 
> There's no reason why a Django site should have to run a database - a 
> microservice using redis or something similar is perfectly reasonable and 
> you could want to use Django for other reasons (e.g. shared templates).
>
> Marc
>
> On 24 February 2015 at 13:38, Marten Kenbeek  
> wrote:
>
>> With recent bug reports (#24332 
>> , #24298 
>>  and now #24394 
>> ) all caused by setting 
>> `DATABASES['default'] = {}`, this makes me wonder if it should be 
>> supported 
>> at all.
>> The documentation states:
>>
>> The DATABASES 
>>> 
>>>  setting 
>>> must configure a default database; any number of additional 
>>> databases may also be specified.[1] 
>>
>>
>> And indeed, if default is not set at all, an error is raised. If 
>> default does not provide valid database settings, it is set to use 
>> `django.db.backends.dummy`. This will raise a `NotImplementedError` as 
>> soon 
>> as it is used, but it seems you can work around this quite well and 
>> ensure 
>> that `default` is barely used. The exceptions to this are reported in 
>> the 
>> mentioned bug reports, most notably `manage.py test` uses the `default` 
>> database. 
>>
>> Should the documentation be clarified that it not only requires 
>> `default` to be set, but that it requires a valid database configuration 
>> as 
>> well? Or should an empty `default` configuration be valid?
>>
>> In #24332 and #24398, both fixed now, there was the additional issue 
>> that the code was simply not using the database is was supposed to use.
>>
>> I think this mostly boils down to whether we want the `test` command 
>> to support an explicit non-default database, you should be able to 
>> manipulate all other code to only use non-default databases, save some 
>> similar bugs that might still be present. This would reduce `default` to 
>> simple semantics and would probably warrant that it is no longer 
>> required 
>> if you supply an otherwise valid database configuration. However, I 
>> don't 
>> see any drawbacks to requiring a valid database setup. At most this 
>> would 
>> require developers to copy the credentials from the database they are 
>> actually using to the `default` setting, but it would also be an 
>> incentive 
>> to actually use `default` as the default database. 
>>
>> [1]  https://docs.djangoproject.com/en/dev/ref/settings/#databases
>>
>> -- 
>> You received this message because you are subscribed to the Google 
>> Groups "Django deve

Re: Composite fields

[Markus Holtermann]

While I like your approach, Thomas, I should also note that I'm not an 
expert on those parts of Django and haven't kept up with the Michal's 
proposal.

With respect to migrations I like Anssi's approach to have both `author` 
and `author_id` in _meta.fields. It will probably simplify a couple of 
things and we can get rid of some workarounds.

Furthermore, I suggest that we take the time and proceed with a DEP 
(https://github.com/django/deps) to find common ground what the API should 
look like before we rush a concrete implementation.

/Markus

On Thursday, March 5, 2015 at 4:07:09 PM UTC+1, Thomas Stephenson wrote:
>
> Well, I was thinking that although the subfields would still be added to 
> Model._meta.fields, you could
>
> - add an 'include_subfields=False' default argument to get_fields()
> - only allow direct lookups of subfields via 
> Model._meta.get_field(composite).get_subfield(subfield) or (alternately, 
> depending on people's tastes) Model._meta.get_field(composite__subfield)
>
> Thomas
>
> On Friday, March 6, 2015 at 1:58:26 AM UTC+11, Marc Tamlyn wrote:
>>
>> I think `Model._meta` may well always want all the concrete underlying 
>> fields included somehow, especially for migrations work. A possibility for 
>> your external `MoneyField` could be to add other fields using 
>> `contribute_to_class`, though this may be a bad idea...
>>
>> On 5 March 2015 at 14:47, Thomas Stephenson  wrote:
>>
>>>  > Turns out this was a bad idea, after around 1700 lines changed 
>>> everything was broken and there were multiple hard to debug failures.
>>>
>>> Yeah, been in this situation too many times to count. 
>>>
>>> > Split ForeignKey to a concrete field instance, and a related field 
>>> instance. After this all related fields are purely virtual. This means that 
>>> author = models.ForeignKey(Author) will automatically generate a author_id 
>>> = IntegerField() on the model. Unfortunately this also means model._meta 
>>> will now contains two fields for each foreign key defined on the model 
>>> instead of just one.
>>>
>>> The foreign_key_id field could be a subfield of foreign key (then 
>>> model._meta would not contain two entries for the foreign key). 
>>> Unfortunately that would open the door to composite field inheritance, but 
>>> it could be handled like enum inheritance is handled in python -- you can 
>>> subclass as much as you want, but you can't declare additional fields on 
>>> subclasses.
>>>
>>> If that happened, then composite foreign keys would be a lot easier (but 
>>> still work that can be deferred). 
>>>
>>> > Michal Petrucha did a lot of work to add composite fields to Django. 
>>> The syntax he had was:
>>>
>>> I'm not exactly a fan of that syntax. It works for the unique_together 
>>> and index_together use cases (and the primary key use case), but it puts 
>>> all the subfields on model._meta and doesn't allow you encapsulate the 
>>> behaviour of composite fields outside the model definition. So you can't, 
>>> for example, define a reusable `MoneyField` that represents two columns in 
>>> the target model.
>>>
>>>
>>> > The first part in the composite fields work should be making the 
>>> point field example to work. This will mean supporting 
>>> .filter(point__in=((1, 2), (2, 3))), and support for .values('point'). Both 
>>> of these will be surprisingly complex to do correctly. In addition there 
>>> will likely be a lot of work to do in other parts of Django, too (for 
>>> example in migrations), so implementing just "simple" composite fields will 
>>> be a lot of work.
>>>
>>> Well, I've already got that working (well, I've got point__exact working 
>>> and I can add point__in easily enough, it's just a matter of adding the 
>>> relevant lookup transformations to get_lookup_transform. There were some 
>>> comments surrounding that function which suggest it needs a refactoring, 
>>> but I don't think it does.
>>>
>>> Thomas
>>>
>>> On 5 March 2015 at 22:30, Anssi Kääriäinen  wrote:
>>>
 I've started doing some refactorings to the fields/related.py. The 
 ultimate goal is to have field.rel (ForeignObjectRel) instances to be 
 Field 
 subclasses.

 I first went ahead and did exactly this with the idea of changing 
 everything in one go. Turns out this was a bad idea, after around 1700 
 lines changed everything was broken and there were multiple hard to debug 
 failures.

 I did a fresh start, and my plan is now to do the following:
   - First, make ForeignObjectRel to act like a Field instance (part of 
 this is done in https://github.com/django/django/pull/4241)
   - Make ForeignObjectRel Field subclass. This will likely rename the 
 classes to something like ReverseForeignKey, ReverseManyToMany and so on.
   - Finally, add the new reverse field instances directly to the remote 
 model's _meta

 This is just clean-up in the fields/related.py. The composite fields 
 work doesn't need to r

Re: django-admin.py shebang

[Markus Holtermann]

Hi Stan,

how did you install Django? As a system package via the system's package 
manager or via pip. If its the system package manager, please raise that bug in 
the bug tracker of your Linux distribution. If the answer is "via pip", from 
where? PyPI or something obscure?

As Collin already wrote, Django uses "/usr/bin/env python" for years.

/Markus


On April 1, 2015 3:58:13 PM GMT+02:00, Collin Anderson  
wrote:
>Hi Stan,
>
>In the source, it's looks like it's been using #!/usr/bin/env python
>for 
>almost 10 years:
>https://github.com/django/django/blame/master/django/bin/django-admin.py
>
>My quick guess is that gets modified when installing. Did you use the
>newer 
>version of python to install django?
>
>Collin
>
>On Wednesday, April 1, 2015 at 7:46:34 AM UTC-4, Stan wrote:
>>
>> Hi devs,
>>
>> Is there a good reason for having the shebang line in django-admin.py
>at 
>> #!/usr/bin/python
>> "instead" of #!/usr/bin/env python ?
>>
>> My problem is I have a newer version of Python installed in 
>> */usr/local/opt/* declared in my PATH 
>> that I want to test but the hardcoded path to /usr/bin/python ignore
>the 
>> PATH value.
>>
>> I know that virtualenv is the way to go...
>>
>> Thanks !
>>
>> --
>> Stan
>>

-- 
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/FEBDCB09-96A0-409D-8801-C674105A881B%40markusholtermann.eu.
For more options, visit https://groups.google.com/d/optout.

Re: 1.9 release planning

[Markus Holtermann]

On Tuesday, April 7, 2015 at 1:21:20 AM UTC+2, Tim Graham wrote:
>
> With a 9 month schedule, here is what the future might look like:
>
> 1.8 - April 2015
> 1.9 - January 2016
> 2.0 - October 2016
> 2.1 - July 2017 (LTS, and might be the last version to support Python 2.7 
> since 3 years of LTS support would cover until the 2020 sunset.)
> 2.2 - April 2018
>
> Do you think there would be any value in putting together a short survey 
> for the community to get a wider consensus?
>

I think the above schedule is a good trade-off between giving companies 
time for their bureaucracy and getting features out to users frequently 
(those who can't (as in "don't want to") wait to use the new features can 
always use the release branch and get involved in testing).

I like the idea of getting the community involved here. But what are we 
planning to say if the majority says "no, that's too often / not often 
enough"? Both, more frequent releases and less frequent releases as they 
happened in the past, have their pros and cons.
 
Markus

On Monday, April 6, 2015 at 5:30:40 PM UTC-4, Shai Berger wrote:
>>
>> On Monday 06 April 2015 23:34:09 Chris Foresman wrote: 
>> > I'm really curious to know if the version to follow 1.9 is planned to 
>> be 
>> > 2.0 or 1.10. I feel as though 1.x releases have had a lot of major 
>> feature 
>> > changes. Maybe it's time to start thinking about features in terms of 
>> > major, minor, and bugfix/security patch, and start saving major 
>> features 
>> > for a 2.0 release that could be LTS. In the meantime, minor features 
>> could 
>> > be added to 1.9, 1.10, 1.11, etc, and breaking API changes should be 
>> added 
>> > to 2.x, or 3.x, etc. This would make it (IMO) easier to evaluate 
>> upgrade 
>> > paths, while maintaining the six-month cadence for .x releases of minor 
>> > features. 
>> > 
>> This was decided a little before 1.7 was released: the version after 1.9 
>> will 
>> be called 2.0, but it is not going to break things more than earlier 
>> releases 
>> (there are already warning classes named RemovedInDjango20Warning and   
>> RemovedInDjango21Warning in the sources, anticipating the releases after 
>> 1.9). 
>>
>> 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/c151c546-dfe1-46f9-9f89-4bc8ee68b133%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Newer version of Sqlite (3.8.9) breaks django -- should we backport

[Markus Holtermann]

For reference, Tim just backported your patch to 1.7 

 
and 1.8 

.

/Markus

On Tuesday, April 14, 2015 at 5:25:28 PM UTC+2, Peter J. Farrell wrote:
>
> Official ticket:
> https://code.djangoproject.com/ticket/24637
>
> PR:
> https://github.com/django/django/pull/4494
>
> Sqlite 3.8.9 which was just released on 4/8/2015 as gold has changed 
> behavior with index_list() functionality by adding 2 more columns of data 
> the returned queryset.  This breaks introspection.py with too many values 
> to unpack.  A PR has been prepared that fixes this for both the new version 
> and older behavior of Sqlite.
>
> The question is should this be backported.  If this bug had been found 
> before the release of Django 1.8, it would have been a blocker for the 
> release. It's clearly a blocking bug and the test suite fail whaled in a 
> few places if your python version was compiled with the newest version of 
> Sqlite.  I think it should be backported to 1.8.  We could document it as 
> an issue for 1.7, but if any security releases need to be made for 1.7 -- 
> it might make sense to me backport it.  I know it's famous last words, but 
> the fix is extremely small so I don't expect any regression since it 
> handles both the old and new behavior from Sqlite.  If anyone can prove 
> otherwise, I'll happily eat my own code fix ;-)
>
> Sqlite usually does 12-15 releases a year.  We've had 5 so far in 2015. 
>  So I suspect we'll see it in the wild with increasing frequency in the 
> coming months as we have 7-10 more Sqlite releases to expect in 2015 if we 
> don't backport it to at least 1.8.
>
> @Tim, since you were the release manager for 1.8 -- what are your 
> thoughts? I defer to those more in the know.
>

-- 
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/90cf54a1-414e-4b16-a8e2-6a00b41710d1%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Must a Django Database Support Migrations?

[Markus Holtermann]

Hey Marvin,

Unfortunately this won't work as a few migration components are tightly 
integrated into remaining parts of Django, e.g. the field deconstruction.

/Markus

On April 18, 2015 3:35:09 AM GMT+02:00, Marcin Nowak  
wrote:
>Hi. 
>Just give people possibility to disable migrations functionality
>(remove it 
>from core and put as a contrib app, if needed).
>
>/BR
>Marcin
>
>
>On Thursday, January 22, 2015 at 8:09:01 PM UTC+1, Andrew Godwin wrote:
>>
>> Aha! Then, I would suggest redesigning MigrationRecorder to only make
>the 
>> table when an actual recording operation is done, and have it swallow
>the 
>> table not existing as "no migrations applied" the rest of the time,
>if 
>> people think that seems sensible.
>>
>> Andrew
>>
>> On Thu, Jan 22, 2015 at 10:44 AM, Markus Holtermann <
>> in...@markusholtermann.eu > wrote:
>>
>>> Hey,
>>>
>>> as soon as the MigrationRecorder is used there is a call to 
>>> "ensure_schema" that forces the creation of the migration table. The
>
>>> runserver command (among others?) checks for unapplied migrations
>and thus 
>>> creates the migration table.
>>>
>>> /Markus
>>>
>>> On Wednesday, January 21, 2015 at 12:36:47 AM UTC+1, Andrew Godwin
>wrote:
>>>>
>>>> Hi Ivan,
>>>>
>>>> I'm not sure what you're asking here - are you asking to have a way
>to 
>>>> not have Django create the migrations recording table? I was under
>the 
>>>> impression that it was only created when migrate was run (at least,
>that 
>>>> was my original intention) so if you're managing your own schema
>just don't 
>>>> run migrate. Is there something else that's not working right, or
>is that 
>>>> being made too optimistically?
>>>>
>>>> Andrew
>>>>
>>>> On Tue, Jan 20, 2015 at 2:44 PM, Ivan VenOsdel 
>wrote:
>>>>
>>>>> From Andrew: "The only extra thing it would achieve is not having 
>>>>> Django record migrations in the django_migrations table"
>>>>>
>>>>> The Django Users thread on how to keep this table from being
>created 
>>>>> seemed to result in the 'solution' being either to stay with 1.6
>or comment 
>>>>> the relevant lines in the Django code base. Is there really no
>other way?
>>>>>
>>>>> I love the new migrations facilities in Django 1.7 and was a 
>>>>> contributor to the kickstarter but please keep in mind that many
>legacy DB 
>>>>> projects are not avoiding migrations because they want to. IMO
>it's usually 
>>>>> because they are forced to for some (usually political) reason
>where they 
>>>>> don't have control over the schema. Forcing a perpetually empty 
>>>>> django_migrations table pretty much locks out those users.
>>>>>
>>>>> I see that people are worried about encouraging the non-use of 
>>>>> migrations but might I suggest following the Zen of Python and
>making 
>>>>> migrations the "one obvious way to do it" and turning them off the
>not 
>>>>> obvious way.
>>>>>
>>>>> Ivan
>>>>>
>>>>> On Wednesday, January 22, 2014 at 5:40:35 AM UTC-6, Andrew Godwin
>wrote:
>>>>>>
>>>>>> My thoughts in brief on this:
>>>>>>
>>>>>>  - Database backends don't support migrations - they support
>schema 
>>>>>> alteration via SchemaEditor. This could be used separately from
>migrations 
>>>>>> if something wants it, and is meant to be an API on its own, so
>the backend 
>>>>>> is not the place to say if you want migrations or not.
>>>>>>
>>>>>>  - There is some merit to the ability to turn off migrations on a
>
>>>>>> per-backend basis, via a DATABASES setting, but bear in mind that
>routers 
>>>>>> already let you do this (with the allow_migrate method). The only
>extra 
>>>>>> thing it would achieve is not having Django record migrations in
>the 
>>>>>> django_migrations table, but it also looks like it would be
>useful for 
>>>>>> tests if you hadn't written that part yet.
>>>>>>
>>>>>>  - I feel like a DB backend should at least 

Re: virtual fields and the migration framework

[Markus Holtermann]

Hey Federico,

I just had a brief look at the code. If I understand 
the HStoreVirtualMixin.contribute_to_class() correctly and its implications 
regarding add_field(), I'd try to use cls._meta.add_field(self, 
virtual=True) instead of a simple cls._meta.add_field(self). That way the 
virtual fields shouldn't show up in migrations at 
all: 
https://github.com/django/django/blob/master/django/db/migrations/state.py#L357 
-- The way the e.g. DictionaryField is implemented, when you put the schema 
into the deconstruct() output, contribute_to_class() should still be called 
generating the additional fields on its own.

Note that this is just a shot in the dark. I didn't try it out myself.

/Markus

On Tuesday, April 21, 2015 at 7:53:04 PM UTC+2, Federico Capoano wrote:
>
> Hi everyone,
>
> some time ago I submitted this ticket: 
> https://code.djangoproject.com/ticket/23159 - because we had problems 
> with the migration framework.
>
> To sum up, the django-hstore 
>  library has a VirtualField 
> implementation which maps hstore keys (by supplying a schema parameter) to 
> virtual fields so that they can be used on models, the admin, and even in 
> django-rest-framework APIs. 
>
> After some interactions with Andrew Godwin, I implemented his suggestion, 
> that was to let db_type() return None, which worked well, until this other 
> issue came up: https://github.com/djangonauts/django-hstore/issues/103
>
> In that case the migration framework would throw an error even if db_type 
> returned None.
>
> Luckily, Tim Graham suggested me how to reach the no-op branch of the 
> migration framework: 
> https://github.com/django/django/blob/190afb86187e42c449afe626cff31f65b4781aa2/django/db/backends/base/schema.py#L470-L475
>
> I met Florian Apolloner at Pycon Italy, so I took advantage of his 
> presence to ask some questions and hear some feedback, which I really 
> appreciated and which really helped me.
>
> I have been able to replicate the bug in a test case and implement the 
> workaround, now comes the interesting part: here's the workaround code:
>
> https://github.com/djangonauts/django-hstore/commit/47f5aa05834365e2d6c41234e03b028a827ee91c
>
> As you can see, I had to add quite some ugly code just to enter that no-op 
> branch there must be a better way! :-D
>
> I talked with Florian about the possibility to have some way to flag 
> virtual fields in order to enter that no-op branch more easily and he was 
> not very sure about it but nonetheless he encouraged me to bring up this 
> issue here. One of the reasons he was not sure is "what happens if a field 
> has the skip flag and then it doesn't or viceversa?"
>
> So I thought about proposing a definition of virtual field:
>
> "A virtual field is a model field which it correlates to one or multiple 
> concrete fields, but doesn't add or alter columns in the database."
>
> By following this definition I suppose we can:
>
>- allow the migration framework to enter the no-op branch if analyzing 
>a virtual field
>- if a concrete field becomes virtual (i can't immagine the use case 
>but i'm reasoning just in case), the migration framework will drop the 
>column, and the developer will have to adjust the migration in order to 
>avoid losing data
>- if a virtual field becomes concrete, the migration framework will 
>add the right column and the developer will have to adjust the migration 
> in 
>order to correctly fill the concrete field with the data that is probably 
>stored in another concrete field
>
> Thank you for your attention.
> Best regards
> Federico Capoano
>

-- 
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/ef6c0525-ffb2-4bc6-8d14-706edd65a142%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Idea/request for help: Django Developers Community Survey

[Markus Holtermann]

It's an amazing idea. Thanks for putting it up, Aymeric and Tim!

Can we add a question regarding usage of test frameworks (i.e., unittest2, 
py.test, nose) similar to "Which popular third-party apps do you rely on?" 
For example "Which test frameworks do you use?" - "unittest2, py.test, 
nose, other". That would allow us to see if we should / can include 
features in django.test that may require a specific framework without 
excluding too many people of our community.

/Markus

On Monday, April 27, 2015 at 9:59:24 PM UTC+2, Thorsten Sanders wrote:
>
>  I wrote in that thread too why I dont like such fast releases and at 
> least someone else asked too to give more options on that one question, on 
> the developer mailing list its kinda only some people who are writing not 
> reflecting all the developers such an survey maybe reach more of them and 
> then the answer about such an important question shouldnt be reduced to 3 
> little options a handfull people decided on, that wouldnt reflect what 
> people really want if they cant choose an real answer.
>
> Am 27.04.2015 02:46, schrieb Tim Graham:
>  
> The idea of the release schedule question is to form consensus on the 
> options that have already been proposed in the "1.9 release planning 
> " 
> thread. If you have a different idea, please propose it there.
>
> On Sunday, April 26, 2015 at 6:53:14 AM UTC-4, Thorsten Sanders wrote: 
>>
>>  I like the idea of an survey, but find the release question with only 3 
>> options quite limited, how about to allow there to put own numbers instead 
>> of giving fixed answers or at least an other field?
>>
>> Am 25.04.2015 14:29, schrieb Tim Graham:
>>  
>> Aymeric and I put together a draft:
>>
>>
>> https://docs.google.com/forms/d/1Owv-Y_beohyCm9o2xPamdBnvjreNYoWai3rDloKZxWw/viewform
>>
>> All questions are optional so you can just click through it to view the 
>> questions. We'll probably clear any responses before its finalized anyway.
>>
>> Let us know if you think we should make any additions or changes.
>>
>> On Wednesday, April 22, 2015 at 4:03:44 AM UTC-4, Federico Capoano wrote: 
>>>
>>> Great idea. 
>>> The questions look good enough to me.
>>>
>>>  I love django-apps or libraries shipped in python packages. One of the 
>>> reason I love Django is the fact that it didn't frenetically add stuff to 
>>> the framework just because it's cool.
>>> The good thing of python packages is that you can get some data from 
>>> pypi (downloads) and github (clones). But we can't do that with contrib 
>>> apps unfortunately.
>>>
>>>  Federico
>>>
>>>
>>> On Saturday, April 18, 2015 at 1:00:13 AM UTC+2, Tim Graham wrote: 

 I had an idea to conduct a survey to get a sense of how developers are 
 using Django. I first had the idea when the question of maintenance of the 
 Oracle GIS backend came up. We really have no idea whether or not anyone 
 is 
 actually using that backend, and it would be helpful to know so we are not 
 wasting resources on unused features. Also there's the question of how 
 often to release Django. I think it would be nice to make that decision 
 based on some data from the community.

 Is anyone is interested in coordinating such a survey (collating 
 questions, preparing the online survey, etc.).

 Some question ideas to get started:

 Which database backend(s) do you use?
 [ ] Checkbox for each one

 Which contrib apps do you use?
 [ ] Checkbox for each one

 How often would you like to see new major version of Django released?
 [ ] List some options, probably between 6 and 9 months.

 Describe which version of Django you use (check all the apply):
 [ ] I only use long-term support releases.
 [ ] I upgrade to the latest stable version as quickly as possible.
 [ ] I run off of master.
 [ ] I upgrade Django when the version I am using is nearing the end of 
 its support (or after).
 [ ] I don't bother upgrading Django, even if it becomes unsupported.
  
>>>   -- 
>> 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/f14071d1-c570-483a-abd2-833e1b47ab4d%40googlegroups.com
>>  
>> 
>> .
>> For more options, visit https://groups.google.com/d/optout.
>>
>>
>>   -- 
> You received this message because you are s

Re: Any Windows users who could help setting up Jenkins slaves?

[Markus Holtermann]

Hey Tim,

I haven't done it myself but if nobody else volunteers I'm up for the 
challenge.

/Markus

On Thursday, April 30, 2015 at 5:49:27 PM UTC+2, Tim Graham wrote:
>
> It would be nice to add Windows support to our continuous integration. Do 
> we have anyone with experience setting up Windows slaves for Jenkins who 
> could help with 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/9b713601-589d-4685-ab85-93f4fa8d9950%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Capturing faked migrations in django_migrations table

[Markus Holtermann]

Hi Steve,

apart from what Tim said, since you commit the migration files as part
of the apps' code to your source code version control system, you can
simply have a look at the commit dates there. I'm not convinced having a
marker for faked migrations in the database is useful.

/Markus

On Wed, May 13, 2015 at 10:20:15AM -0700, Tim Graham wrote:

I'm curious to know the reason why it would be helpful to know whether or
not a migration was faked. When you fake a migration, you are promising
that your schema matches the migration, so it seems to me that it would
only matter if you made a mistake there.

On Wednesday, May 13, 2015 at 12:38:38 PM UTC-4, steve byerly wrote:


I couldn't find any related discussions on this topic, but I would find it
helpful to have documentation whether a specific migration was faked or
not. This would allow someone to look at all migrations that have been run
and see which ones were actually applied.

My use case is migrating a large project to django 1.7. Since there are
many apps in the project the initial migrations generated are not all 0001
- 0002, 0003 both present. These will all get faked, but it's not obvious
in 6 months that migration 0003 in one app that was created as part of
initializing migrations was faked vs migration 0003 in another app that was
applied.

Adding a NullBooleanField to the model would solve the issue, but I'm not
positive if this is good practice.

Thanks for the input in advance.
-Steve



--
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/a39cbdcd-c797-4db5-89be-98cffbddf2ba%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/20150513172703.GA5391%40pyler.local.
For more options, visit https://groups.google.com/d/optout.


pgpzmdDuOlPqg.pgp
Description: PGP signature

Re: Capturing faked migrations in django_migrations table

[Markus Holtermann]

I think having the Python logging module outputting the things the 
migrations framework does, seems to be a good idea. I can see some use 
cases where people want to turn that on.

I opened an issue to keep track of the feature 
request: https://code.djangoproject.com/ticket/24800

/Markus

On Thursday, May 14, 2015 at 1:39:02 AM UTC+2, Andrew Godwin wrote:
>
> I agree a log would be helpful, but I'm not sure that should be stored in 
> the database? We could either add a history/audit table in the database or 
> we could have some way of configuring a logger that stores locally (which 
> is a much higher bar, but presumably where sysadmins actually want logs?)
>
> Andrew
>
> On Wed, May 13, 2015 at 2:05 PM, Shai Berger  > wrote:
>
>> I think we had this discussion, more-or-less, around South migrations (I
>> looked a little, but couldn't find it). The context there was, as Tim 
>> hinted,
>> "forensics" -- trying to figure out how a system came into its (broken) 
>> state.
>> For that (as well as the OP's case, AFAICT) it makes little sense to add 
>> a flag
>> in the migration history (really, "applied migrations") table, but it does
>> make sense to have some sort of "migrations log", which would have a 
>> record
>> for every migration executed (including backwards).
>>
>> Shai.
>>
>> On Wednesday 13 May 2015 20:34:19 Andrew Godwin wrote:
>> > I agree with Markus/Tim - the whole point of faked migrations is that
>> > they're meant to exactly match the existing schema. If Django is
>> > auto-faking migrations that don't match the existing one that would be a
>> > bug, but it's almost too conservative in that aspect.
>> >
>> > Are you manually faking these migrations? Or having Django do it for you
>> > and getting it wrong?
>> >
>> > Andrew
>> >
>> > On Wed, May 13, 2015 at 10:27 AM, Markus Holtermann <
>> >
>> > in...@markusholtermann.eu > wrote:
>> > > Hi Steve,
>> > >
>> > > apart from what Tim said, since you commit the migration files as part
>> > > of the apps' code to your source code version control system, you can
>> > > simply have a look at the commit dates there. I'm not convinced 
>> having a
>> > > marker for faked migrations in the database is useful.
>> > >
>> > > /Markus
>> > >
>> > > On Wed, May 13, 2015 at 10:20:15AM -0700, Tim Graham wrote:
>> > >> I'm curious to know the reason why it would be helpful to know 
>> whether
>> > >> or not a migration was faked. When you fake a migration, you are
>> > >> promising that your schema matches the migration, so it seems to me
>> > >> that it would only matter if you made a mistake there.
>> > >>
>> > >> On Wednesday, May 13, 2015 at 12:38:38 PM UTC-4, steve byerly wrote:
>> > >>> I couldn't find any related discussions on this topic, but I would 
>> find
>> > >>> it
>> > >>> helpful to have documentation whether a specific migration was 
>> faked or
>> > >>> not. This would allow someone to look at all migrations that have 
>> been
>> > >>> run
>> > >>> and see which ones were actually applied.
>> > >>>
>> > >>> My use case is migrating a large project to django 1.7. Since there 
>> are
>> > >>> many apps in the project the initial migrations generated are not 
>> all
>> > >>> 0001
>> > >>> - 0002, 0003 both present. These will all get faked, but it's not
>> > >>> obvious in 6 months that migration 0003 in one app that was created 
>> as
>> > >>> part of initializing migrations was faked vs migration 0003 in 
>> another
>> > >>> app that was
>> > >>> applied.
>> > >>>
>> > >>> Adding a NullBooleanField to the model would solve the issue, but 
>> I'm
>> > >>> not positive if this is good practice.
>> > >>>
>> > >>> Thanks for the input in advance.
>> > >>> -Steve
>> > >>
>> > >> --
>> > >> 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 ema

Re: Deprecate internal syncdb in 1.9 ?

[Markus Holtermann]

After some discussion with other members of the core team, we think that we 
might re-evaluate the point of dropping support for apps without 
migrations. But this highly depends on the outcome of what Andrew is going 
to achieve in https://code.djangoproject.com/ticket/24481#comment:6 with 
regards to the last point. Depending on the actual overhead that comes up 
there we'll may or may not enforce migrations for all apps at some point.

The deprecation timeline marks the removal of support for apps without 
migration a part of 1.9. However, since the reason for putting that on the 
deprecation timeline was that syncdb used to use the old DDL code, this 
argument does not hold anymore. syncdb uses the same DDL code as migrations.

/Markus

On Wednesday, June 3, 2015 at 1:16:37 PM UTC+2, Andriy Sokolovskiy 
(coldmind) wrote:
>
> After discussion with Markus Holtermann, we decided that we need to 
> deprecate internal syncdb in 1.9 (
> https://github.com/django/django/blob/7c637a3aaec311269bf863c220bf894eebbe7c7c/django/core/management/commands/migrate.py#L136
> )
> The fact that apps without migrations are not supported, which is 
> documented for current master, is not fully right, because migrate command
> is still calling syncdb inside.
> I think it is time to drop support of apps without migrations internally, 
> so in 2.0, after users will be warned in 1.9, we can remove syncdb and 
> create
> schema only from migrations and require all installed apps with models to 
> have migrations.
>

-- 
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/7d2fd535-40b3-4c83-845b-72d248096587%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: 1.9 release planning

[Markus Holtermann]

Thanks Loic, that helps A LOT!

I'm +1 on a semver or semver-ish policy. I don't have a favorite of the
proposed. And I'm +-0 on changing e.g. 1.9 to 2.0 or whatever is
required to match the new release policy.

/Markus

On Tue, Jun 16, 2015 at 02:15:59PM +0700, Loïc Bistuer wrote:

I've attempted to summarize the history of this thread. Note that I marked as 
+1 any generally positive feedback towards a given proposal, please correct if 
you feel misrepresented.


# First iteration:

1/ Release every 8 months (previously undefined).

2/ LTS every 3rd releases (previously undefined but effectively 1.8 is the 4th 
release after 1.4). Thanks to point 1/ it means one LTS release every two years.

3/ LTS releases are supported for 3 years (previously undefined). Combined with 
points 1/ and 2/ this gives us 1 year of support overlap between 2 LTS 
(currently we committed as an afterthought to 6 months overlap between 1.4 LTS 
and 1.8 LTS).

Core +1: Tim, Marc, Markus, Collin, Aymeric, Loïc


# Second iteration:

4/ Deprecation shims must appear in a LTS release before being dropped.

So far this is the only real change in the policy, first iteration only 
adjusted and/or pinned variables.

In practice, thanks to point 2/, this only requires one exception to our 
current policy: features deprecated in the release *immediately following* an 
LTS have to be supported for 1 extra release. (e.g 1.9 
PendingDeprecationWarning, 2.0 PendingDeprecationWarning, 2.1 
DeprecationWarning). In return this makes it easier for 3rd-party apps to 
straddle 2 LTS releases without writing their own shims (provided their code 
runs without deprecation warnings on the oldest LTS).

Core +1: Collin, Carl, Tim, Anssi, Michael, Loïc

Refs:
- django-compat thread 
(https://groups.google.com/d/topic/django-developers/ASnZ5Uyol6Y/discussion)
- Collin's proposal 
https://groups.google.com/d/msg/django-developers/MTvOPDNQXLI/hou67ofj3EYJ and 
the 7 following responses.


# Third iteration:

5/ Switching to Semantic Versioning

Donald mentioned SemVer on IRC a few days ago. Since then various proposal were 
made to reconcile it with our release policy. So far Collin, Carl, Loïc, Tim, 
and Josh have expressed positive feedback to various proposals in that 
direction but I don't think we have yet reached consensus on a specific one. 
Tim updated the Google doc to reflect my latest proposal, so including me 
that's 2 formal +1 for it, but I'd say we should wait for at least a couple 
more votes before taking it to the technical board.

Refs:
- http://semver.org/
- Carl's analysis 
https://groups.google.com/d/msg/django-developers/MTvOPDNQXLI/Ojov2QBROg8J
- Ryan's proposals 
https://groups.google.com/d/msg/django-developers/MTvOPDNQXLI/lBLWrhKJ6DIJ
- Loïc's proposal 
https://groups.google.com/d/msg/django-developers/MTvOPDNQXLI/y2QbPVzSs6cJ

Cheers

--
Loïc


On Jun 16, 2015, at 02:37, Aymeric Augustin 
 wrote:

If we're approaching consensus, could a kind soul put together a final proposal 
and submit it to the technical board, along with the main arguments or 
alternatives? I'm finding it difficult to follow this 50-message thread... 
Thanks :-)


--
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/B8FE1DF4-1542-465B-B3DE-A7CA0DE5C3BB%40gmail.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/20150616124159.GF25232%40pyler.local.
For more options, visit https://groups.google.com/d/optout.


pgpYsNc2aWalH.pgp
Description: PGP signature

Re: 1.9 release planning

[Markus Holtermann]

+1 -- Going with 1.8, 1.9, 1.10, 1.11 (LTS), 2.0 sounds like a solid
plan. I don't think any of the (Pending)DeprecationWarnings are much of
a public API. I've never seen them in the wild.

/Markus

On Mon, Jun 22, 2015 at 11:20:52AM -0400, Michael Manfre wrote:

+1. I really don't like the idea of 2.x being odd.

On Mon, Jun 22, 2015 at 10:33 AM, Loïc Bistuer 
wrote:


Just when we thought we had a winner... I'd like to make a final proposal.

Instead of delaying adoption of SemVer to 3.0 we could do so in 2.0 by
introducing the 1.10 and 1.11LTS releases.

The upside is that the new policy applies right away and we avoid the
oddball 2.0 and 2.1 releases.

It's much less invasive than the previous idea of renaming 1.9 to 2.0, but
it still requires renaming PendingDeprecationWarnings in 1.8, and both
warnings in 1.9.

What do you think?

--
Loïc

> On Jun 17, 2015, at 08:47, Josh Smeaton  wrote:
>
> I'm also +1 on the proposal as it stands, and neutral on when the semver
versioning should begin.
>
> On Wednesday, 17 June 2015 05:03:47 UTC+10, Michael Manfre wrote:
> I'm +1 on the Google doc proposal and like Markus, I support relabeling
1.9 to 2.0 to line the versions up with the new paradigm without the X.1
LTS oddball.
>
> Regards,
> Michael Manfre
>
> On Tue, Jun 16, 2015 at 12:34 PM, Collin Anderson 
wrote:
> I also like the gdoc as it is. (1.8 LTS, 1.9, 2.0, 2.1 LTS, 3.0, 3.1,
3.2 LTS, 4.0, etc.) LTS is the final of a major version number, and we
sacrifice a little bit of strict semver, but it give some nice meaning to
the version numbers.
>
>
> On Tuesday, June 16, 2015 at 12:22:44 PM UTC-4, Carl Meyer wrote:
> Thanks Loïc,
>
> On 06/16/2015 01:15 AM, Loïc Bistuer wrote:
> > I've attempted to summarize the history of this thread. Note that I
> > marked as +1 any generally positive feedback towards a given
> > proposal, please correct if you feel misrepresented.
> >
> [snip]
> >
> > # Third iteration:
> >
> > 5/ Switching to Semantic Versioning
> >
> > Donald mentioned SemVer on IRC a few days ago. Since then various
> > proposal were made to reconcile it with our release policy. So far
> > Collin, Carl, Loïc, Tim, and Josh have expressed positive feedback to
> > various proposals in that direction but I don't think we have yet
> > reached consensus on a specific one. Tim updated the Google doc to
> > reflect my latest proposal, so including me that's 2 formal +1 for
> > it, but I'd say we should wait for at least a couple more votes
> > before taking it to the technical board.
> >
> > Refs: - http://semver.org/ - Carl's analysis
> >
https://groups.google.com/d/msg/django-developers/MTvOPDNQXLI/Ojov2QBROg8J
> >
> >
> - Ryan's proposals
>
https://groups.google.com/d/msg/django-developers/MTvOPDNQXLI/lBLWrhKJ6DIJ
> > - Loïc's proposal
> >
https://groups.google.com/d/msg/django-developers/MTvOPDNQXLI/y2QbPVzSs6cJ
>
> FWIW, I am also +1 on your proposal, as currently documented in the
> Google doc.
>
> I was trying to come up with a proposal where LTS == major release for
> the sake of argument, since it seemed like that was intuitive to at
> least some people, but it's not worth the required lengthening of
> deprecation paths. Your proposal is much better. (And it does make some
> intuitive sense for the _last_ minor release in a major series to be LTS
> rather than the first).
>
> 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-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/ebc7b0ae-27aa-4848-a6b5-9cec4b374895%40googlegroups.com
.
>
> For more options, visit https://groups.google.com/d/optout.
>
>
>
> --
> GPG Fingerprint: 74DE D158 BAD0 EDF8
> keybase.io/manfre
>
> --
> 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/79aae5a5-58dd-4f05-a6dd-35685e06ebb5%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-dev

Re: naming of a new test client method for logging in

[Markus Holtermann]

I second Andriy's comment.

/Markus

On Tue, Jun 30, 2015 at 04:41:06PM +0300, Andriy Sokolovskiy wrote:

force_login() seems to be more clear what it going on inside

On 6/30/15 16:38, Tim Graham wrote:

There's a proposal [1] to add a new method to the test client that works
like login(), but skips the authentication (no credentials need to be
provided) and verification (is_active=False can login) steps. The
signature is (user, backend=None). What would you name this method?

Proposals so far:
* force_login() (since this method bypasses authentication and other
checks login() has)
* login_user() (since this method takes a user argument instead of
credentials)

[1] https://github.com/django/django/pull/4865

--
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/896e32fc-67ea-4c56-ac90-b8e47a00c7ea%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/55929C72.3060008%40asokolovskiy.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/20150630162053.GA5329%40pyler.local.
For more options, visit https://groups.google.com/d/optout.


pgpJ0zsJAR2Z_.pgp
Description: PGP signature

Re: metaclass expertise needed on migrations bug

[Markus Holtermann]

Thanks for brining this to my attention, Tim! I just commented on the
issue: https://code.djangoproject.com/ticket/25068#comment:12

/Markus

On Thu, Jul 09, 2015 at 01:13:11PM -0700, Tim Graham wrote:

To someone with experience with metaclasses,

A high-level overview of this ticket/pull request would be appreciated:

https://code.djangoproject.com/ticket/25068
https://github.com/django/django/pull/4968

--
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/e59496cd-f666-44c7-b583-a8f147d95e9c%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/20150714124947.GA7894%40pyler.local.
For more options, visit https://groups.google.com/d/optout.


pgpRDQBSNE6Oh.pgp
Description: PGP signature

Re: Why Django is making migrations for external apps?

[Markus Holtermann]

Hi all,

While your proposal could solve the repeated creation of migrations due to 
dynamic choices, Simon, I don't see how it would solve or prevent the issue 
Carl mentioned earlier. Data migrations may need to have the exact choices at 
that particular state. Importing the current choices may fail the migration 
process on a new database. Furthermore, I think exposing such a feature would 
encourage people to use it for the wrong reasons, ending up with hard to debug 
bugs.

I favor Andrew's proposal to revisit the white listing of field attributes on a 
per-field-instance level, eg:

class MyModel(models.Model):
name = models.CharField(…)
name.migrations_exclude_attributes = {'choices'}

That would be 100% backwards compatible and the autodetector would only need to 
check if the changed attribute is in that particular set and ignore the change 
in case it is. Since this property only takes effect when used with the current 
model, I don't see a need to maintain its presence or value in migrations.

/Markus

On July 17, 2015 11:46:15 AM GMT+10:00, charettes  wrote:
>Hi everyone,
>
>Here's just an idea from the top of my head.
>
>What if we exposed a `django.db.migrations.Reference`
>that would be a deconstructible proxy to a top level module object.
>It would be initialized with a module name string and the referenced
>object name as a second argument. We could document
>such an object should be returned by fields deconstruct()
>method to opt-in the desired behavior described by Carl.
>
>We already do something similar with the string setting case with
>`django.db.migration.writer.SettingReference` which could be
>a simple subclass of `Reference` that takes a single setting
>name argument instead and pass `django.conf.settings` to it's
>parent initializer.
>
>Thoughts?
>
>Simon
>
>Le jeudi 16 juillet 2015 12:25:50 UTC-4, Carl Meyer a écrit :
>>
>> Hi Andrew and Marcin, 
>>
>> On 07/15/2015 05:10 PM, Andrew Godwin wrote: 
>> > Django persists every single field attribute change, no matter what
>it 
>> > is - this was a deliberate decision as we didn't want to declare
>certain 
>> > attributes as "not important for schema" (for example, a subclass
>of 
>> > ChoiceField might use an enum column type for the choices and so
>need 
>> > that change). 
>>
>> There's another reason for this choice: accuracy of the "historical"
>or 
>> "frozen" ORM used in data migrations. Even if a field attribute has
>no 
>> effect on the database schema, it could have a significant effect on
>the 
>> Python-level behavior in a data migration. For instance, it's
>entirely 
>> possible that a data migration could use a `get_FOO_display` method, 
>> which could certainly break if the choices on that field at that
>point 
>> in "migration time" are not correctly preserved in the migrations. 
>>
>> > That said, this is definitely a common problem and I'm starting to
>think 
>> > we should revisit it - specifically, have field classes themselves
>say 
>> > which attributes are not worth making changes for (perhaps combined
>with 
>> > greater control by fields over how their schema gets made). This
>isn't 
>> > currently possible though. 
>>
>> If we do this, I think it should be opt-in and used only by the end 
>> developer for unusual cases (like dynamic choices). The default
>should 
>> continue to be to preserve all field attributes, including choices,
>for 
>> frozen-ORM reasons. 
>>
>> 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/558942CF-B06A-4538-AEDC-6691B9635A08%40markusholtermann.eu.
For more options, visit https://groups.google.com/d/optout.

Re: Simplifying MANIFEST.in

[Markus Holtermann]

On Wed, Jul 22, 2015 at 09:40:08AM -0700, Tim Graham wrote:

Lately we've had some packaging problems due to mistakes in MANIFEST.in,
mostly due to missing files in the source distribution because we forgot to
update MANIFEST.in for new or moved files. Currently it looks like this:

include README.rst
include AUTHORS
include INSTALL
include LICENSE
include MANIFEST.in
include django/contrib/auth/common-passwords.txt.gz
include django/contrib/gis/gdal/LICENSE
include django/contrib/gis/geos/LICENSE
include django/dispatch/license.txt
include django/dispatch/license.python.txt
recursive-include docs *
recursive-include scripts *
recursive-include extras *
recursive-include tests *
recursive-include django/conf/app_template *
recursive-include django/conf/locale *
recursive-include django/conf/project_template *
recursive-include django/contrib/*/locale *
recursive-include django/contrib/admin/templates *
recursive-include django/contrib/admin/static *
recursive-include django/contrib/admindocs/templates *
recursive-include django/contrib/auth/templates *
recursive-include django/contrib/gis/static *
recursive-include django/contrib/gis/templates *
recursive-include django/contrib/sitemaps/templates *
recursive-exclude * __pycache__
recursive-exclude * *.py[co]

Despite all the rules for django/, it seems the only difference in there is
that django/contrib/admin/bin isn't included in the distribution. Is there
a reason not to do something like:

recursive-include django *
prune django/contrib/admin/bin

This seems to generate the same result except that the missing
django/contrib/auth/common-passwords.txt.gz (forgot to add) is correctly
included.

On a related note, should the new JavaScript tests also be included in the
distribution?


If we ship the Python tests we should also ship the JS tests, IMO.

/Markus


--
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/2996a59b-09ab-4dc2-bba5-cc5c868f81f1%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/20150723014359.GA3500%40pyler.local.
For more options, visit https://groups.google.com/d/optout.


pgpuWSpLe2KI1.pgp
Description: PGP signature

Re: Why Django is making migrations for external apps?

[Markus Holtermann]

On Mon, Jul 20, 2015 at 11:56:40AM -0600, Carl Meyer wrote:

On 07/20/2015 11:47 AM, Shai Berger wrote:

On Monday 20 July 2015 18:47:07 Carl Meyer wrote:



Personally I don't really see much use case for this feature
except as a workaround for reusable apps that generate spurious new
migrations based on settings changes


I've also seen it with apps that use "EmailField" without specifying
explicit length (which I'd expect to be the common way to use it...)


Why would this cause a spurious new migration?



It's arguably a bug in the reusable app. The app supported Django 1.7. Then
they wanted to support Django 1.8, and its change of the default length of
EmailField. So they added a migration that enlarges the field from 75 to 254.
This actually makes a lot of sense for anybody upgrading from 1.7 to 1.8.
However, if you use it with 1.7, makemigrations wants to add a migration to
pull it back down to 75.

I'm not sure what the reusable app was supposed to do here. They could drop
support for 1.7 (or limit it to the older branch). They could make a separate
release for each of the versions, differentiated only by the presence of the
migration file. They could specify explicitly one of the lengthes, which would
make their EmailFields incompatible with other default EmailFields (if there
is ever reason to copy values from a field in one model to another, and these
things do happen). None of these options are without prices. Even detecting
the Django version in the migration and picking the length accordingly is
problematic (if the migration is run before the Django upgrade, it will miss
its purpose).

The bug in the app is still open:
https://github.com/omab/python-social-auth/issues/622


I see, thanks for the explanation. ISTM that the best available solution
for this situation is to specify the length of the field explicitly to
254. Yes, this means that a Django 1.7 user copying an email address
from the social-auth email field to some other default-length email
field might have to figure out what to do with emails longer than 75
characters, but a) that's not likely a common case, and b) such a user
has the migration system available to just lengthen their own email
field with an explicitly-specified length, too.

Carl


The recommended way is to specify the length explicitly and use the
lowest Django version to generate migrations you want to support.

/Markus


--
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/55AD3658.5090902%40oddbird.net.
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/20150723014647.GB3500%40pyler.local.
For more options, visit https://groups.google.com/d/optout.


pgpQXtwOx5j0j.pgp
Description: PGP signature

Re: Keeping apps without migrations?

[Markus Holtermann]

Instead of rushing to a decision if and of how we continue to support
"apps w/o migrations" I would argue that, since Django's test suite does
infact create tables for apps w/o migrations, we could add a commandline
flag (e.g. --run-syncdb or whatever) to the migrate command and warn the
user if there are apps w/o migrations an the user doesn't supplied:
https://github.com/django/django/blob/master/django/core/management/commands/migrate.py#L136

/Markus

On Thu, Aug 06, 2015 at 05:26:50PM -0700, Andrew Godwin wrote:

Do we know exactly what "support for apps without migrations" would consist
of at this point? I have that half-done code for replicating syncdb with
the autodetector stuck onto the migration executor, but it's not especially
speedy and would need some work to make it a sensible speed before it goes
forward.

Alternately, we could modify the autodetector to have a "create only" mode
that's more efficient or just write a new generator that is quick because
it knows it's only making nonmigrated apps' migrations.

Andrew

On Thu, Aug 6, 2015 at 4:56 PM, Tim Graham  wrote:


With the alpha for 1.9 coming up in 6 weeks, we need to decide whether or
not to continue support for apps without migrations (currently in master no
tables are created for such apps (as the deprecation timeline says), but it
might be appropriate to add a warning or error message for this case if
things don't change).

Is anyone sufficiently interested in continuing support for apps without
migrations to commit to completing it by the alpha? If not, do you consider
it a release blocker that I should spend time on?

Related tickets:

https://code.djangoproject.com/ticket/25144 - No way to create tables for
apps without migrations
https://code.djangoproject.com/ticket/24919 - Add an option not to run
migrations when running tests
https://code.djangoproject.com/ticket/24481 - Improve sqlmigrate to be
more flexible and allow bypassing migrations on disk
https://code.djangoproject.com/ticket/24901 - makemigrations should
create empty migrations dir for any installed app without it
https://code.djangoproject.com/ticket/24588 - Improve handling apps
without migrations while running migrate command.

On Sunday, January 18, 2015 at 5:11:53 PM UTC-5, Markus Holtermann wrote:


Creating in-memory migrations for all apps that don't have migration
files seems to be an option to solve the dependency problem. This would
even allow apps without migrations to depend on those with migrations.

We have to consider though, that there are tens of apps and hundreds of
models in our own test suite, and generating all migrations during start
seems to be quite an expensive task. And I'm not even talking about the
migration optimizer which probably needs to get a lot smarter if we take
this road.

syncdb, which leaves a developer with a database scheme that cannot be
altered automatically, is something we should get rid of as soon as
possible, especially since Django has a out-of-the-box migration system.

/Markus

On Sun, Jan 18, 2015 at 01:50:14PM -0800, Andrew Godwin wrote:
>My main argument for removing them entirely was the dependency issues
>between apps with and without migrations. Having syncdb use SchemaEditor
is
>a big step and one I'm happy we've got to, but the only advantage of
>keeping syncdb is for the test suite and I'd rather we approach that
more
>as "migrations made and run at runtime as a special case" rather than
>"syncdb".
>
>If nothing else, I'd like to see the end-developer-facing parts, like
the
>syncdb command itself, gone.
>
>Andrew
>
>On Sun, Jan 18, 2015 at 1:43 PM, Claude Paroz 
wrote:
>
>> Tim recently did a fabulous job of removing deprecated code for the
>> future 1.9 on master. Thanks for that.
>>
>> However, one thing he removed was support for apps without migrations.
>>
>>
https://github.com/django/django/commit/7e8cf74dc74539f40f4cea53c1e8bba82791fcb6
>>
>> Considering that we have to keep internal support for Django's own
test
>> suite anyway, I wonder if we should remove that support at all for
>> "normal" projects. I think one of Andrew's motivation was not to have
to
>> keep two schema editing code bases. But now that the old syncdb also
>> uses the new schema editor, I think that this argument doesn't stand.
>>
>> So what about keeping support for apps without migrations in the
longer
>> term. Of course, the fact that those apps cannot depend on migrated
apps
>> limits its use, but I think that for quick prototyping and initial
>> developement, migrations could be more of a hindrance. Would you see
>> major drawbacks with keeping this support?
>>
>> Opinions welcome.
>>
>> Claude
>> --
>&

Re: Django Admin New Look

[Markus Holtermann]

Hey,

Looking at some browser market share stats
(http://www.sitepoint.com/browser-trends-august-2015-chrome-exceeds-50/
, disclaimer:
http://www.sitepoint.com/how-browser-market-share-is-calculated/) IE8
seems hardly be used anyway. Furthermore, with the dropped support for
IE8 (and 9+) on Jan 12th, 2016
(https://support.microsoft.com/en-us/lifecycle/search?sort=PN&alpha=internet%20explorer),
I don't really see any problem in removing IE8 support and notifying the
users that they have to update to a modern browser.

Therefore I find Aymeric's proposed solution "You are using an old web
browser ..." a reasonable choice over being stuck with ages old
technology that is long outdated.

/Markus

PS: I'd go with SVG solution

On Tue, Aug 18, 2015 at 04:13:11AM -0700, Tim Graham wrote:

I also had the idea of upgrading jQuery to jQuery 2 which drops support for
IE6/7/8, but I guess this will break all the JavaScript in the admin under
those browsers. Do you think that's unacceptable at this time? If so, could
you propose an alternate timetable for the upgrade?

On Tuesday, August 18, 2015 at 3:32:18 AM UTC-4, Aymeric Augustin wrote:


On 18 août 2015, at 01:28, Tim Graham >
wrote:

> Unless someone can present an argument for keeping IE8 support, I
wouldn't worry about it considering it will be end of life about 1 month
after the release of Django 1.9.

Let’s just make sure the admin stays usable, even if it looks bad. Since
we’re taking the SVG route, providing an alt text on icons should do.

We could be explicit about the lack of support for IE8 and lower by adding
a conditional message in the template:



--
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/e541a69a-2ded-4af1-b049-f144878c0f83%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/20150818113357.GA1859%40pyler.local.
For more options, visit https://groups.google.com/d/optout.


pgpgFEniLPuy7.pgp
Description: PGP signature

Re: Pre-DEP: community support of unmaintained versions of Django

[Markus Holtermann]

Hey Christian,

On Wed, Aug 19, 2015 at 02:41:49PM -0700, Christian Hammond wrote:

Regarding the version number, from what I've read, there's still a reported
compatibility issue if we use the +localidentifer part of a version number
with older versions of setuptools. I need to do some testing on this. If I
don't hit any issues, I'm very happy to put an identifier on there. I would
like to keep it at 1.6.11.x, rather than 1.6.12+, so that it's very clear
we're based on upstream Django 1.6.11.


Thanks, that sounds good to me. 1.6.11.x+unofficial if possible,
otherwise 1.6.11.x


I want HTTPS on this pretty badly, though, so we might try that
approach when we can get to it.


Good :)


To attempt to compensate for this, though, we sign all the builds and
include checksums in both the links and in dedicated .sha256sum files. Not
the best solution, but it's something at least :/


Checksums alone won't provide integrity checks if I can play MITM. Only
(e.g. pgp) signatures will help. But then make sure the key ID is
published on an HTTPS page ;)

/Markus


On Wed, Aug 19, 2015 at 9:08 AM, Carl Meyer  wrote:


Hi Christian,

On 08/18/2015 08:01 PM, Christian Hammond wrote:
[snip]
> Also as a status update, we've started a fork and applied for the
> pre-notification list. I've backported all current security fixes to a
> branch, ensured the test suite passes with flying colors, and have added
> a README detailing everything you've requested. This is all up at
> https://github.com/beanbaginc/django. Let me know if there's anything
> you'd like changed.

One thing was pointed out to me just now -- the downloads page _really_
should use TLS. Any chance you could make that happen?

Carl

--
You received this message because you are subscribed to a topic in the
Google Groups "Django developers  (Contributions to Django itself)" group.
To unsubscribe from this topic, visit
https://groups.google.com/d/topic/django-developers/69fOquu8v-U/unsubscribe
.
To unsubscribe from this group and all its topics, 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/55D4AA04.3090403%40oddbird.net
.
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/CAHfcSbz%3DN9%2BFduAcSODtTVLEVmbD42Nu_CsiJHAQiXxtU70kCg%40mail.gmail.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/20150819234311.GA2502%40pyler.local.
For more options, visit https://groups.google.com/d/optout.


pgphn7ufHtysd.pgp
Description: PGP signature

Re: Keeping apps without migrations?

[Markus Holtermann]

The general benefit of *not* having migrations is the incredible better 
performance to setup the tables. Especially for larger projects this is 
something we should at least keep in mind 
(see https://code.djangoproject.com/ticket/24743). I spent a fair bit of 
time on the issue and have not yet found a satisfying solution.

Supporting apps without migrations would essentially continue to support 
the old `syncdb` behavior, though not as a standalone command, but as a 
flag for `manage.py migrate`. It takes the models from those apps and calls 
`schema_editor.create_model()`, taking the deferred SQL and running it 
after all models of apps w/o migrations have been created (current behavior 
[in tests] I think). This would continue to raise issues if models in apps 
w/o migrations refer to models in apps w/ migrations (missing constraints), 
but that is a limitation we had since 1.7 (silent failure; 1.8 fails loud).

While migrations should provide *the* way to maintain your database I see 
the points that have been made in other recent discussions. Although Django 
doesn't force you to use migrations there are some things (e.g. not create 
the `django_migrations` table) we probably should not do unless you 
actually use migrations.

We might want to consider looking at the `MIGRATION_MODULES` settings 
variable and allowing to set values to `None` in order to disable 
migrations for that app, but that's a different story.

/Markus

On Friday, August 28, 2015 at 4:26:19 AM UTC+10, Tim Graham wrote:
>
> It would be great if we could decide this by next Friday (September 4) or 
> so, so that we have some time to do the necessary implementations and 
> testing before alpha. (For example, running manage.py test without 
> migrations currently gives "no such table ...". It would be nice to give a 
> friendlier message if we require migrations for running tests 
> (https://github.com/django/django/pull/5100 does this to some extent, but 
> could be improved I think).
>
> I know at least Markus said he would like to present an argument for 
> keeping support for apps without migrations.
>
> On Thursday, August 13, 2015 at 1:56:05 PM UTC-4, Tim Graham wrote:
>>
>> It's a one line change in the code to keep the status quo from 1.8. The 
>> main drawback I see is continued support tickets about dependencies between 
>> apps with and without migrations. I already removed the documentation 
>> describing the problem and "won't fixed" tickets that suggested doing more 
>> to detect and throw errors about these cases.
>>
>> I guess I'd like here why migrations could be a hindrance "for quick 
>> prototyping and initial development." I'd argue that starting with 
>> migrations from the start (manage.py makemigrations && manage.py migrate) 
>> will save the need to learn about --fake-initial if you decide to add 
>> migrations at some point later (and of course avoid dependency issues). Is 
>> "manage.py makemigrations && manage.py migrate" more difficult that the 
>> proposed ""manage.py migrate --allow-apps-without-migrations"? Am I missing 
>> a motive behind the request?
>>
>> diff --git a/django/core/management/commands/migrate.py 
>> b/django/core/management
>> index 2f04824..dec86e1 100644
>> --- a/django/core/management/commands/migrate.py
>> +++ b/django/core/management/commands/migrate.py
>> @@ -133,7 +133,7 @@ class Command(BaseCommand):
>>  targets = executor.loader.graph.leaf_nodes()
>>  
>>  plan = executor.migration_plan(targets)
>> -    run_syncdb = options.get('run_syncdb') and 
>> executor.loader.unmigrated_a
>> +run_syncdb = bool(executor.loader.unmigrated_apps)
>>  
>>  # Print some useful info
>>  if self.verbosity >= 1:
>>
>> On Thursday, August 6, 2015 at 9:50:10 PM UTC-4, Markus Holtermann wrote:
>>>
>>> Instead of rushing to a decision if and of how we continue to support 
>>> "apps w/o migrations" I would argue that, since Django's test suite does 
>>> infact create tables for apps w/o migrations, we could add a commandline 
>>> flag (e.g. --run-syncdb or whatever) to the migrate command and warn the 
>>> user if there are apps w/o migrations an the user doesn't supplied: 
>>>
>>> https://github.com/django/django/blob/master/django/core/management/commands/migrate.py#L136
>>>  
>>>
>>> /Markus 
>>>
>>> On Thu, Aug 06, 2015 at 05:26:50PM -0700, Andrew Godwin wrote: 
>>> >Do we know exactly what "support for apps without migrations" would 

Re: Keeping apps without migrations?

[Markus Holtermann]

Hey Anssi,

thanks for the ideas. A few comments inline

On Friday, August 28, 2015 at 3:25:34 PM UTC+10, Anssi Kääriäinen wrote:
>
> Could we allow applications to have fake migration files? I'm thinking 
> of something like operations.AllModelsUpdated(). After this operation 
> is ran, Django will use the present models for that app. You could 
> place this as your last migration, and run direct SQL in previous 
> migrations (or use some completely different mechanism) . Direct SQL 
> without model state changes will be fast. The last migration would 
> supposedly be fast, as it only needs to construct up to date images of 
> the current models. 
>

That is something you can already do by using 
`SeparateDatabaseAndState` 
https://docs.djangoproject.com/en/1.8/ref/migration-operations/#django.db.migrations.operations.SeparateDatabaseAndState.
 
Use RunSQL for the Database part and CreateModel for the state part.

The problem is that I'm not at all sure how this will mix with 
> migrations from other applications, so this proposal is perhaps 
> technically impossible to do. But if this is feasible, then it should 
> be possible to mix migrations and manual database changes pretty much 
> seamlessly. This one would work much better if we had project level 
> migrations - implementing a migration operation that tells Django that 
> all of the project's models are up to date is almost trivial. 
>

I don't see how project level migrations would make that easier. Unless you 
have only changes to the data in the database Django won't change any SQL 
and will happily reuse the latest models up to that state.

I believe a fake migration would work pretty well for the use case 
> where you want to use manual database control for your project, but 
> use 3rd party applications with migrations. 
>
> Another idea I've been thinking is that maybe we could have snapshots 
> for migrations. The reason I believe this would work is that building 
> the model state is expensive, but in many cases it is completely 
> redundant to build the model state from scratch. 
>
> The snapshots would essentially do the following operation: after 
> migrations X, Y and Z are applied the model state will be as presented 
> in this migration. The snapshots would only contain model state, not 
> any operations. When you run manage.py migrate, the app state builder 
> will be able to skip to latest snapshot that has all dependencies 
> already applied, and then continue building model state from there. 
> When performance begins to degrade, you can create a new snapshot. The 
> snapshots would probably have to be project level to work properly. 
> This would seriously speed up migrations, except for the case where 
> you run the migrations against fresh database. 
>

You are only half right: the performance problem is the *rendering* of the 
models from the model states. However I don't see how having checkpoints 
would help, reusing the state. It would help to not need to create the 
state up until that point, but the performance issue there got resolved I 
think. The main problem is models having 'object references' to other 
models (`models.ForeignKey(User)` vs `models.ForeignKey('auth.User')`). In 
order to have consistent references between two model classes (i.e. 
`ModelA._meta.get_field('fk_to_modelb').related_model is ModelB`) all 
related models have to be rerendered once one 
changes: 
https://github.com/django/django/blob/master/django/db/migrations/state.py#L32
 

>  - Anssi 
>

/Markus
 

> On Fri, Aug 28, 2015 at 3:18 AM, Andrew Godwin  > wrote: 
> > I think I agree with Markus that we do not yet have a good enough 
> > performance story to make migrations mandatory. If you want to ditch 
> them 
> > and do your own database management, we should let you - which we could 
> do 
> > with some kind of MIGRATIONS_MODULES opt-out that basically sets 
> everything 
> > to pseudo-unmanaged, but I see no reason not to have the syncdb-like 
> > solution keep working as it at least runs off of SchemaEditor now. 
> > 
> > Andrew 
> > 
> > On Thu, Aug 27, 2015 at 5:14 PM, Markus Holtermann 
> > > wrote: 
> >> 
> >> The general benefit of *not* having migrations is the incredible better 
> >> performance to setup the tables. Especially for larger projects this is 
> >> something we should at least keep in mind (see 
> >> https://code.djangoproject.com/ticket/24743). I spent a fair bit of 
> time on 
> >> the issue and have not yet found a satisfying solution. 
> >> 
> >> Supporting apps without migrations would essentially continue to 
> support 
> >> the old `syncdb` behavior, though not

Re: Ability to migrate other applications

[Markus Holtermann]

Thank you for your patches and ideas of how to solve this feature, 
Emmanuelle.

However, I strongly agree with Andrew that, if we allow this -- I'm on 
Tim's side here, it feels odd encouriging something that's not considered 
to be used for that purpose: `contribute_to_class` -- the solution should 
be in the MigrationLoader. But as Andrew already said, you *will have* 
problems when you have your own migrations and a third party app adds a new 
one. Suddenly there are two leafs which is an invalid state. You will have 
to run `manage.py makemigrations --merge theapp` to fix this. The only sane 
solution I see right now is allowing MIGRATION_MODULES to take a string or 
list as values for each app. At which point Django needs to know where to 
place the merge-migration. I'd go with the first item in the list.

However, I still don't like the idea either and would and will continue to 
recommend to copy the migration files as proposed by Tim earlier.

/Markus

On Thursday, September 3, 2015 at 4:09:46 AM UTC+10, Emmanuelle Delescolle 
wrote:
>
>
> My main concern is not with the complexity of your proposed patch but with 
>> committing to supporting a new API that solves a problem that can already 
>> be solved a different way (albeit maybe less elegantly). Anyway, I don't 
>> want to speak definitely about the issue, but it seems like if we keep 
>> thinking about the problems maybe we could come up with a more elegant 
>> solution that doesn't need to marked as "dangerous".
>>
>
> Well, my first idea was to have a re-usable app deal with this case, this 
> is actually how I've been handling it thus far. The problem with my current 
> "reusable" app is that it's not very re-usable since there is no easy way 
> of doing hat the path does in a re-usable app without copy-pasting most of 
> the Django file because the migrated app is "hard-coded" to self.app_label 
> and I now have 3 versions of that code depending on which version of Django 
> is being used.
>
> So here is what I'm thinking: here is another patch 
> https://github.com/django/django/compare/master...nanuxbe:migrate_other_app 
> which would allow for a third party tool to be written while not adding any 
> feature to Django.
> Then Django doesn't have to actually support the feature (and therefore 
> isn't responsible for it) while still allowing it.
>
> What do you think?
>

-- 
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/86db9454-b9b6-404c-af62-c9d2fc1ff0ef%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Password validation in Django revisited

[Markus Holtermann]

Hey,

while I like the idea of having the validation in all places to not forget 
one that might be user facing, I was surprised by the fact that the 
validation also happens in dev environments when you create the superuser 
(this whole mail applies to the changepassword command, too):

$ python manage.py createsuperuser
Username (leave blank to use 'markus'):
Email address: 
Password:
Password (again):
This password is too short. It must contain at least 8 characters.
Password:
Password (again):
The password is too similar to the email address.
Password:


This is a bit annoying for me, given that I normally use "markus" or 
"admin" as username and password for the superuser and u1:u1, as 
username:password combination for additional users.

There are a few solutions to that behavior I'd like to see revisited for 
1.9:

   1. Disable password validation when DEBUG=True -- I don't think we 
   really want that
   2. Don't have password validation for createsuperuser/changepassword: I 
   personally don't see the benefit for that in the command anyways.
  1. In production environments I would expect the admins having access 
  to the management command to know their regulations (after all, they need 
  to configure them) and to know what good passwords are. 
  2. As somebody who is able to run the "createsuperuser" command I 
  figure I can also run "shell", giving me unlimited access to the password 
  field of users, allowing me to set a password that doesn't match the 
  requirements.
  3. It breaks backwards compatibility with tools like Expect 
  (https://en.wikipedia.org/wiki/Expect -- yes, I had to use that in the 
past)
   3. Disable validation when passing --no-validate or 
   --no-validate-password to createsuperuser, though this is still backwards 
   incompatible and a lot to type -- I'd better of with having a valid 
   password -- or the other way around, passing --validate / 
   --validate-password, but this feels pointless

My preference is definitely (2), though I'm sorry for not bringing this up 
earlier when the issue was created.

The original issue: https://code.djangoproject.com/ticket/25089
Respective PR: https://github.com/django/django/pull/5073

Cheers,

/Markus

On Thursday, July 9, 2015 at 6:13:18 PM UTC+10, Alex Becker wrote:
>
> Hi Erik,
>
> I've written such a patch, which also fixes an html escape bug and adds 
> validation to the auth management commands.
> The pull request is here .
>
> Sincerely,
>
> Alex
>
> On Friday, June 26, 2015 at 3:19:30 AM UTC-5, Erik Romijn wrote:
>>
>> Hi Alex, Carl, 
>>
>> On 22 Jun 2015, at 02:43, Carl Meyer  wrote: 
>> > On 06/21/2015 06:17 PM, Alex Becker wrote: 
>> >> With the PR merged, password validation applies to the SetPasswordForm 
>> >> and the password changing forms, but not to the UserCreationForm or to 
>> >> the creation of superusers. Is there a reason not to apply validation 
>> to 
>> >> these as well? 
>> > 
>> > Certainly makes sense to me to add validation to both of these. I 
>> missed 
>> > it in review. Erik, is there a reason you didn't, or was it just an 
>> > oversight? 
>>
>> No reason at all. I hadn’t even realised there was such a form. It seems 
>> sensible to add it (along with a test), but I don’t have time to make the 
>> patch currently. 
>>
>> Erik
>
>

-- 
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/9860adf7-b0b3-492d-b8a0-f08c7b85b587%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Password validation in Django revisited

[Markus Holtermann]

Hey Aymeric,

I think I'd prefer "downgrade the message to a warning and proceed" for 
DEBUG=True and list all validation errors, much like for forms. Sticking to 
the current implementation for DEBUG=False is fine with me. For example:

$ python manage.py createsuperuser
Username (leave blank to use 'markus'):
Email address: 
Password:
Password (again):
The passwords do not match.
Password:
Password (again):
You used a password that doesn't fulfill all validation requirements:
  - This password is too short. It must contain at least 8 characters.
  - The password is too similar to the email address.

Superuser successfully created

Cheers,

/Markus

On Saturday, September 5, 2015 at 5:14:16 PM UTC+10, Aymeric Augustin wrote:
>
> Hello,
>
> Indeed, this will be annoying for development.
>
> I don’t find the “admins don’t need rules, they know what they’re doing” 
> argument compelling. The cobbler children’s go barefoot… Besides, if admins 
> know the rules, having validation enabled won’t hurt :-)
>
> I’m in favor of implementing an escape hatch when DEBUG = True:
>
> - either downgrade the message to a warning and proceed
> - or ask the user if they want to proceed with the invalid password 
> (--no-input would skip this step and proceed silently)
>
> -- 
> Aymeric.
>
>
>
> On 5 sept. 2015, at 01:56, Markus Holtermann  > wrote:
>
> Hey,
>
> while I like the idea of having the validation in all places to not forget 
> one that might be user facing, I was surprised by the fact that the 
> validation also happens in dev environments when you create the superuser 
> (this whole mail applies to the changepassword command, too):
>
> $ python manage.py createsuperuser
> Username (leave blank to use 'markus'):
> Email address: 
> Password:
> Password (again):
> This password is too short. It must contain at least 8 characters.
> Password:
> Password (again):
> The password is too similar to the email address.
> Password:
>
>
> This is a bit annoying for me, given that I normally use "markus" or 
> "admin" as username and password for the superuser and u1:u1, as 
> username:password combination for additional users.
>
> There are a few solutions to that behavior I'd like to see revisited for 
> 1.9:
>
>1. Disable password validation when DEBUG=True -- I don't think we 
>really want that
>2. Don't have password validation for createsuperuser/changepassword: 
>I personally don't see the benefit for that in the command anyways.
>   1. In production environments I would expect the admins having 
>   access to the management command to know their regulations (after all, 
> they 
>   need to configure them) and to know what good passwords are. 
>   2. As somebody who is able to run the "createsuperuser" command I 
>   figure I can also run "shell", giving me unlimited access to the 
> password 
>   field of users, allowing me to set a password that doesn't match the 
>   requirements.
>   3. It breaks backwards compatibility with tools like Expect (
>   https://en.wikipedia.org/wiki/Expect -- yes, I had to use that in 
>   the past)
>3. Disable validation when passing --no-validate or 
>--no-validate-password to createsuperuser, though this is still backwards 
>incompatible and a lot to type -- I'd better of with having a valid 
>password -- or the other way around, passing --validate / 
>--validate-password, but this feels pointless
>
> My preference is definitely (2), though I'm sorry for not bringing this up 
> earlier when the issue was created.
>
> The original issue: https://code.djangoproject.com/ticket/25089
> Respective PR: https://github.com/django/django/pull/5073
>
> Cheers,
>
> /Markus
>
> On Thursday, July 9, 2015 at 6:13:18 PM UTC+10, Alex Becker wrote:
>>
>> Hi Erik,
>>
>> I've written such a patch, which also fixes an html escape bug and adds 
>> validation to the auth management commands.
>> The pull request is here <https://github.com/django/django/pull/4969>.
>>
>> Sincerely,
>>
>> Alex
>>
>> On Friday, June 26, 2015 at 3:19:30 AM UTC-5, Erik Romijn wrote:
>>>
>>> Hi Alex, Carl, 
>>>
>>> On 22 Jun 2015, at 02:43, Carl Meyer  wrote: 
>>> > On 06/21/2015 06:17 PM, Alex Becker wrote: 
>>> >> With the PR merged, password validation applies to the SetPasswordForm
>>>  
>>> >> and the password changing forms, but not to the UserCreationForm or to
>>>  
>>> >> the creati

Re: Ability to migrate other applications

[Markus Holtermann]

On Wednesday, September 9, 2015 at 9:21:43 PM UTC+10, Shai Berger wrote:
>
>
>
> On 9 בספטמבר 2015 13:29:58 GMT+03:00, Marten Kenbeek  > wrote: 
> > 
> >> 
> >> The order of migrations isn't something which is local to this 
> >feature, it 
> >> is something which isn't fixed (probably by design, correct me if I'm 
> > 
> >> wrong) and if it is not "the right way" to do it, maybe it should be 
> >part 
> >> of another issue. 
> > 
> > 
> >The order of migrations within a single app is fixed. 
>
> No, actually it isn't. It is only constrained by dependencies. Merge 
> migrations do not fix it either. The only thing they do is tell the 
> warning-happy migration system : "yes, I have considered the situation here 
> and it's OK to run these two migrations in either order ". 
>
No, they do ensure some sort of deterministic behavior. Migrations are 
sorted by their fully qualified name (tuple of (app_label, migration_name)):
https://github.com/django/django/blob/master/django/db/migrations/graph.py#L64

This behavior is enough for a 3rd party app to destroy the results of your 
own migration or the other way round.

Consider a.1 <-- a.2 <-- b.1 where b.1 makes changes to the app a. When the 
author of app a add another migration a.3 (a.1 <-- a.2 <-- (a.3, b.1)) the 
resulting order in which migrations are applied will be a.1, a.2, a.3, b.1. 
However, on an existing database, a.3 will be run after b.1, resulting in a 
non-deterministic order in which migrations for the same app are being 
applied.

Consider me a strengthened -1 looking at the discussion.

If we want to have something like "project level migrations" we should 
rethink a bunch of things, but that's out of scope of the initial proposal 
of this discussion, I think.

>
> Which raises two points : 
>
> First, can we (do we want to ) handle this validation some other way, and 
> would it buy us anything? 
>
> Second, how common is Marten's misconception? Do we need to address it? 
>
>
> Shai 
> -- 
> Sent from my Android device with K-9 Mail. Please excuse my brevity. 
>

/Markus 

-- 
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/c0de9532-5527-4ac5-9e6c-9a3475f9c342%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Capturing faked migrations in django_migrations table

[Markus Holtermann]

Hey there,

here's a pull request for this 
feature: https://github.com/django/django/pull/5279 . I'd appreciate some 
review.

/Markus

On Wednesday, May 20, 2015 at 9:25:00 AM UTC+10, steve byerly wrote:
>
> Awesome, thank you very much for the detailed answer.
> -Steve
>
> On Tue, May 19, 2015 at 4:16 PM, Shai Berger  > wrote:
>
>> Hi Steve,
>>
>> On Wednesday 20 May 2015 01:50:15 steve byerly wrote:
>> >
>> > I'm also unclear what the argument against storing in the migrations 
>> table
>> > is vs logging them - honest question. Since I have 4 web servers, the
>> > information would be logged to any one of them - depending on which
>> > executed the migration during deploy.
>> >
>>
>> The argument is, basically, that logging solves a more general use-case, 
>> and
>> so it is a better solution for the problem.
>>
>> Your use case, as you described it:
>>
>> > During a deploy, it's really nice to make sure you faked the right
>> > migrations/didn't fake the wrong migrations
>>
>> fits in the general pattern of "I want to know what happened in this 
>> system".
>> Logging, as far as we understand, solves that problem. The migrations 
>> table
>> solves a different problem -- it records which migrations the system 
>> considers
>> to have been executed, to support the decision of which migrations to run
>> (when asked to). One of the outstanding "conflicts" between the two goals 
>> is
>> encountered when a migration is rolled back: For "decision support", the
>> simplest handling is to delete the migration's record from the table (and 
>> this
>> is what Django does, AFAIK). For "forensics", this behavior is quite
>> unacceptable.
>>
>> The most natural solution for knowing what happened in a system is 
>> logging.
>> When you have 4 servers, you want some federated logging anyway -- 
>> migrations
>> are probably not the only case where something that happens on one server
>> affects the behavior of others. Be that as it may, Python's logging 
>> library
>> allows you to set different handlers for different loggers -- so, assuming
>> migrations get their own logger, it shouldn't be very hard to set up 
>> logging
>> so that all migration logging goes to some special place. That place can 
>> even
>> be the database -- see e.g. https://pypi.python.org/pypi/django-logdb (I 
>> have
>> no personal experience with that package, I just searched for it).
>>
>> HTH,
>> 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/d1a9dd7e-86c8-402f-bd5a-8c2a674bf63e%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Capturing faked migrations in django_migrations table

[Markus Holtermann]

First of all, thanks for all the feedback!

While the PR is in a good state there's one discussion happening with a 
decision that needs to be made:

The current Django documentation states that log messages are send to the 
console from INFO level an up. However, because of a misconfiguration this 
is not true; messages are logged for WARNING and above 
(see https://github.com/django/django/pull/5289 for a patch for that, see 
discussion at 
https://groups.google.com/forum/#!topic/django-developers/no2IhnRty68). 
Giving the updated default configuration, sending log messages to any 
logger in the `django` namespace ('django.*') will show up on the command 
line when run on DEBUG=True. This may make sense for `django.request` as 
that is issued from the runserver command, but at least the newly 
introduced `django.db.migrations` logger is not too helpful on the console. 
Even for `django.db` (query logging) I'm not too happy for it to show up in 
`manage.py shell` but like it in `manage.py runserver`.

I see the following solutions to bring this PR forward:

   1. Configure `django.db.migrations` logger to not send messages to 
   console by default and keep log levels to INFO (for "Applied/Unapplied 
   migration XYZ") and DEBUG (for "Marked migraiton XYZ as applied/unapplied")
   2. Change the log levels for both messages to DEBUG
   3. Don't propagate messages from `django.db.migrations` logger to parents
   4. Don't go forward with the above mentioned patch amending the default 
   log level

I prefer option 1 and clearly document how people can activate the logger, 
while option 2 is currently implemented but comes with the disadvantage 
that you can't separate the two log levels. Option 3 works too, but could 
cause some weird behavior and confusion if not documented why it's set. 
Option 4, no idea, it sounds correct to me.

/Markus

On Sunday, September 13, 2015 at 10:08:15 AM UTC+10, Markus Holtermann 
wrote:
>
> Hey there,
>
> here's a pull request for this feature: 
> https://github.com/django/django/pull/5279 . I'd appreciate some review.
>
> /Markus
>
> On Wednesday, May 20, 2015 at 9:25:00 AM UTC+10, steve byerly wrote:
>>
>> Awesome, thank you very much for the detailed answer.
>> -Steve
>>
>> On Tue, May 19, 2015 at 4:16 PM, Shai Berger  wrote:
>>
>>> Hi Steve,
>>>
>>> On Wednesday 20 May 2015 01:50:15 steve byerly wrote:
>>> >
>>> > I'm also unclear what the argument against storing in the migrations 
>>> table
>>> > is vs logging them - honest question. Since I have 4 web servers, the
>>> > information would be logged to any one of them - depending on which
>>> > executed the migration during deploy.
>>> >
>>>
>>> The argument is, basically, that logging solves a more general use-case, 
>>> and
>>> so it is a better solution for the problem.
>>>
>>> Your use case, as you described it:
>>>
>>> > During a deploy, it's really nice to make sure you faked the right
>>> > migrations/didn't fake the wrong migrations
>>>
>>> fits in the general pattern of "I want to know what happened in this 
>>> system".
>>> Logging, as far as we understand, solves that problem. The migrations 
>>> table
>>> solves a different problem -- it records which migrations the system 
>>> considers
>>> to have been executed, to support the decision of which migrations to run
>>> (when asked to). One of the outstanding "conflicts" between the two 
>>> goals is
>>> encountered when a migration is rolled back: For "decision support", the
>>> simplest handling is to delete the migration's record from the table 
>>> (and this
>>> is what Django does, AFAIK). For "forensics", this behavior is quite
>>> unacceptable.
>>>
>>> The most natural solution for knowing what happened in a system is 
>>> logging.
>>> When you have 4 servers, you want some federated logging anyway -- 
>>> migrations
>>> are probably not the only case where something that happens on one server
>>> affects the behavior of others. Be that as it may, Python's logging 
>>> library
>>> allows you to set different handlers for different loggers -- so, 
>>> assuming
>>> migrations get their own logger, it shouldn't be very hard to set up 
>>> logging
>>> so that all migration logging goes to some special place. That place can 
>>> even
>>> be the database -- see e.g. https://pypi.python.org/pypi/dja

Re: Feature Proposal: per-settings fake migration override

[Markus Holtermann]

Hi Flavio,

This sounds like a very risky and scary proposal, to be honest. The recommended 
way would indeed be to fake the initial migration(s) on production. 

Since it seems to me that this would only ever be needed once (you said devs 
should just run the migration locally and the table is too big for any changes) 
I'd probably go with the one time fake. 

Alternatively, as of Django 1.9 you could move the transaction log model into a 
dedicated app and disable migrations for that app.

As a last resort, why not make the model unmanaged (Meta.manage=False) and 
apply the respective operations manually with RunSQL operations?

That are the ideas that just came to mind, there are probably others as well.

/Markus

On September 19, 2015 6:38:59 AM GMT+10:00, Flavio Curella 
 wrote:
>I'm not sure if this warrants a DEP, so I've decided to post it to the
>list 
>first. If this needs to be a DEP, just let me know and I'll follow the
>DEP 
>process.
>
>Rationale
>-
>
>Assume the following scenario:
>
>1. At some point in history, project A was deployed in production and
>was 
>very successful.
>2. The project created a table called `transactions_log`, which is now 
>considerably big and full of very valuable data, that we want to
>retain.
>3. Because of $reasons$, project B gets started as a future replacement
>of 
>project B
>4. Project B wants to reuse `transactions_log` and the 
>`transaction.models.Log` model unaltered
>
>What we have is a 'split' between what the initial migration for the 
>`transaction.models.Log` model should do, between dev and production:
>
>* On local dev, it simply creates the table
>* On production, the migration must be faked.
>
>Traditionally, we would go to the person in charge of migration and
>tell 
>them 'Hey, migration `transactions.0001_initial` must be faked'.
>But this seems error-prone. That information ('fake this one specific 
>migration') could be lost in the communication workflow, and imposes
>the 
>cognitive burden of having to remember another special case.
>
>Proposed solution
>
>
>Assume the following settings files:
>
>```
># settings/local.py
># ..usual list of settings...
>```
>
>```
># settings/production.py
>MIGRATION_FAKE = (
>('transactions', '0001_initial),
>)
>```
>
>* On `django-admin.py migrate --settings=settings.local`, the migration
>
>`transactions.0001` will be faked only if the `--fake` flag is passed 
>(previous behavior).
>* On `django-admin.py migrate --settings=settings.production`, the 
>migration `transactions.0001` will *always* be faked. The new setting
>will 
>act as an ad-hoc, per-migration override of the global `--fake` option.
>
>I have a branch up as a Proof of Concept at 
>https://github.com/fcurella/django/tree/feature/adhoc-fake (no test or
>doc 
>changes yet). The code change necessary seems to be minimal, let me
>know if 
>you think it's something worth having.
>
>Thank you,
>–Flavio.

-- 
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/12F5779F-E1C9-4473-AF92-B52851465694%40markusholtermann.eu.
For more options, visit https://groups.google.com/d/optout.

Re: status of 1.9 release blockers

[Markus Holtermann]

I did not fully follow the discussion, but by the amount of email 
notifications I got on that PR if feels to me that deferring it to 1.10 
would be the better option, also considering what Tom said about this being 
part of a core component and it has to be done right.

/Markus

On Wednesday, September 23, 2015 at 2:54:50 AM UTC+10, Tim Graham wrote:
>
> The second patch has been committed, and the first one is still under 
> review. 
>
> Florian says "with all that forth and back [on the pull request] I am not 
> sure if it is not better to defer it to 1.10, i.e. I completely missed the 
> base64 stuff for instance. One option would be to ship it with the 
> feature inactive and mark it as experimental and ask users to try it out. 
> Though, that would probably be a first."
>
> I'd also be more comfortable if it were disabled by default. The main 
> problem for me is the documentation doesn't really motivate the feature 
> very well and describe how one should go about setting the values of the 
> new settings.
>
> Options:
> 1) Defer the patch to 1.10 and release the alpha today.
> 2) Maintain the feature freeze until the end of the week to see if the 
> patch is better resolved by then (fix bugs on master in the meantime) and 
> release the alpha then (whether or not the patch is completed).
> 3) Create the 1.9 branch today to allow normal development to proceed on 
> master and release the alpha by the end of the week with the option to 
> backport the patch if it's completed.
>
> Opinions?
>
> On Monday, September 21, 2015 at 9:08:22 PM UTC-4, Tim Graham wrote:
>>
>> Let's consider master feature frozen for now. There are two more patches 
>> I'd like to merge before we cut the 1.9 branch.
>>
>> #21231 -- Enforced a max size for POST values read into memory
>> https://github.com/django/django/pull/3852
>> Status: Needs final code reviews and probably some doc enhancements (docs 
>> could possibly be deferred until after alpha). Florian & Shai, as you've 
>> been taking the lead on reviewing this, please let us know your thoughts.
>>
>> #24509 -- Added Expression support to SQLInsertCompiler
>> https://github.com/django/django/pull/5324 
>> Status: Josh working on some doc enhancements now, I will review in the 
>> morning.
>>
>> On Friday, September 18, 2015 at 10:03:45 AM UTC-4, Marc Tamlyn wrote:
>>>
>>> Sorry everyone :(
>>>
>>> On 18 September 2015 at 15:01, Tim Graham  wrote:
>>>
 The major features are officially deferred. Let's try for the feature 
 freeze by end of day on Monday and the alpha release on Tuesday.

 There aren't any critical blockers at this time. Jani hasn't completed 
 the Oracle GIS work, but this isn't a must-have for alpha.


 On Saturday, September 12, 2015 at 7:50:31 PM UTC-4, Tim Graham wrote:
>
> With 1 week to go until alpha:
>
> I haven't heard anything from Marc or Preston on the major features 
> from the last mail.
>
> Jani continues to give updates in #django-dev about his progress on 
> getting the Oracle GIS backend working. Things seem to be on track for 
> finishing up by alpha.
>
> On Friday, September 4, 2015 at 3:55:22 PM UTC-4, Tim Graham wrote:
>>
>> Status with 2 weeks and a weekend to go until alpha (Monday, 
>> September 21).
>>
>> Planned major features for 1.9:
>>
>> PostgreSQL Full Text Search (Marc Tamlyn)
>>
>> I haven't seen any recent activity on the pull request, nor have I 
>> heard anything from Marc about it.
>> https://github.com/django/django/pull/4726
>>
>> Custom indexes (Marc Tamlyn)
>>
>> I haven't see any work on revising the DEP, so this seem out for 1.9.
>>
>> https://github.com/django/deps/pull/6
>>
>> Template-based widget rendering (Preston Timmons)
>> I think the code is in fairly good shape. It seems the main work left 
>> to is to write documentation.
>> https://github.com/django/django/pull/4848
>>
>> Release blockers:
>>
>> - Add Oracle support for new-style GIS functions
>> https://code.djangoproject.com/ticket/24688
>> Owner: Jani Tiainen
>> Status: In progress (from recent IRC discussion, it sounds like Jani 
>> is making good progress)
>>
>> On Monday, August 24, 2015 at 3:40:22 PM UTC-4, Tim Graham wrote:
>>>
>>> Time to kickoff the progress tracker for the next major release!
>>>
>>> Here's the status with 4 weeks to go until alpha (September 21).
>>>
>>> Release blockers:
>>>
>>> - Add Oracle support for new-style GIS functions
>>> https://code.djangoproject.com/ticket/24688
>>> Owner: Jani Tiainen
>>> Status: In progress (test suite runs on Oracle now, which is an 
>>> improvement from last week)
>>>
>>>
>>> Other tickets tagged for 1.9:
>>>
>>> - No way to create tables for apps without migrations
>>> https://code.djangoproject.com/ticket/25144

Re: Non-atomic migrations in Django?

[Markus Holtermann]

Hi Ludwig,

the API looks clean and sensible to me. +1 for getting that into 1.10

/Markus

On November 25, 2015 12:00:59 AM GMT+10:00, "Ludwig Hähne"  
wrote:
>Hi all,
>
>I'd like to get your feedback on supporting non-atomic migrations in
>Django.
>
>Database transactions are always wrapped in transactions (on DBs that 
>support transactional DDL like Postgres). Generally this is a good
>idea. 
>
>However, one can't do batched updates in data migrations which is
>essential 
>for performing changes on big tables on a live DB [1]. It's also not 
>possible to create indexes concurrently on Postgres from inside a 
>transaction.
>
>Therefore, I'd like to have support for non-atomic migrations in Django
>
>because it's pretty messy to work around not having proper support for
>that 
>[2].
>
>Here's a proof-of-concept implementation [3] of exempting specific 
>migrations from being wrapped in a transaction by setting `atomic =
>False` 
>on the migration:
>
>https://github.com/django/django/compare/master...Ableton:non-atomic-migrations
>
>Do you agree that non-atomic migrations should be supported by Django?
>
>Is setting an `atomic` property on a migration a good API for that?
>
>If there's a chance this will be merged, I'd add documentation,
>incorporate 
>your feedback, and open a ticket or PR.
>
>Thanks,
>Ludwig
>
>[1] http://pankrat.github.io/2015/django-migrations-without-downtimes/
>[2] 
>http://stackoverflow.com/questions/31247810/commit-manually-in-django-data-migration
>[3] 
>https://github.com/django/django/compare/master...Ableton:non-atomic-migrations

-- 
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/704E30F0-A249-45CD-B084-FCECCF711E88%40markusholtermann.eu.
For more options, visit https://groups.google.com/d/optout.

Re: worth adding PyPy to continuous integration?

[Markus Holtermann]

Hey Tim,

I think we should at least run the tests occasionally and see if they pass and 
if not see how much effort it takes to fix problems.

Regarding the migration date issues, I fixed them in newer PyPy versions: 
https://bitbucket.org/pypy/pypy/issues/2062/inconsistency-in-__repr__-for-date-time

/Markus

On December 3, 2015 2:46:38 AM GMT+10:00, Tim Graham  
wrote:
>Once in a while, we get a ticket about failures when running the Django
>
>test suite on PyPy. Sometimes they are bugs in PyPy, other times we use
>
>something that's not available or behaves differently in PyPy. Is it
>worth 
>adding PyPy to our continuous integration so we can proactively address
>
>these issues?
>
>(We can't test with pypy3 since that's based on Python 3.2 which we've 
>dropped support for in Django 1.9.)
>
>Recent tickets:
>https://code.djangoproject.com/ticket/24779
>https://code.djangoproject.com/ticket/25844
>
>Current failures with pypy 2.4.0 and Django 1.9:
>
>==
>ERROR: test_serialize_datetime (migrations.test_writer.WriterTests)
>--
>Traceback (most recent call last):
>File "/home/tim/code/django/tests/migrations/test_writer.py", line 248,
>
>in test_serialize_datetime
>self.assertSerializedEqual(datetime.datetime.utcnow)
>File "/home/tim/code/django/tests/migrations/test_writer.py", line 179,
>
>in assertSerializedEqual
>self.assertEqual(self.serialize_round_trip(value), value)
>File "/home/tim/code/django/tests/migrations/test_writer.py", line 175,
>
>in serialize_round_trip
>string, imports = MigrationWriter.serialize(value)
>File "/home/tim/code/django/django/db/migrations/writer.py", line 540,
>in 
>serialize
>"topics/migrations/#migration-serializing" % (value,
>get_docs_version())
>ValueError: Cannot serialize: 'datetime.datetime'>>
>There are some values Django cannot serialize into migration files.
>For more, see 
>https://docs.djangoproject.com/en/dev/topics/migrations/#migration-serializing
>
>==
>ERROR: test_simple_migration (migrations.test_writer.WriterTests)
>--
>Traceback (most recent call last):
>File "/home/tim/code/django/tests/migrations/test_writer.py", line 459,
>
>in test_simple_migration
>output = writer.as_string()
>File "/home/tim/code/django/django/db/migrations/writer.py", line 167,
>in 
>as_string
>operation_string, operation_imports = 
>OperationWriter(operation).serialize()
>File "/home/tim/code/django/django/db/migrations/writer.py", line 124,
>in 
>serialize
>_write(arg_name, arg_value)
>File "/home/tim/code/django/django/db/migrations/writer.py", line 76,
>in 
>_write
>arg_string, arg_imports = MigrationWriter.serialize(item)
>File "/home/tim/code/django/django/db/migrations/writer.py", line 357,
>in 
>serialize
>item_string, item_imports = cls.serialize(item)
>File "/home/tim/code/django/django/db/migrations/writer.py", line 433,
>in 
>serialize
>return cls.serialize_deconstructed(path, args, kwargs)
>File "/home/tim/code/django/django/db/migrations/writer.py", line 318,
>in 
>serialize_deconstructed
>arg_string, arg_imports = cls.serialize(arg)
>File "/home/tim/code/django/django/db/migrations/writer.py", line 540,
>in 
>serialize
>"topics/migrations/#migration-serializing" % (value,
>get_docs_version())
>ValueError: Cannot serialize: 'datetime.datetime'>>
>There are some values Django cannot serialize into migration files.
>For more, see 
>https://docs.djangoproject.com/en/dev/topics/migrations/#migration-serializing
>
>==
>ERROR: test_band_data_setters 
>(gis_tests.gdal_tests.test_raster.GDALBandTests)
>--
>Traceback (most recent call last):
>File "/home/tim/code/django/tests/gis_tests/gdal_tests/test_raster.py",
>
>line 357, in test_band_data_setters
>bandmem.data(packed_block, (1, 1), (2, 2))
>File "/home/tim/code/django/django/contrib/gis/gdal/raster/band.py",
>line 
>133, in data
>data_array = ctypes_array.from_buffer_copy(data)
>AttributeError: type object 'c_ubyte_Array_4' has no attribute 
>'from_buffer_copy'
>
>==
>FAIL: test_prefetch_related_queryset
>(model_forms.tests.OtherModelFormTests)
>--
>Traceback (most recent call last):
>File "/home/tim/code/django/tests/model_forms/tests.py", line 2308, in 
>test_prefetch_related_queryset
>(red_item.pk, 'red'),
>  File "/home/tim/code/django/django/test/testcases.py", line 93, in 
>__exit__
>query['sql'] for query in self.captured_queries
>AssertionError: 2 queries executed, 4 expected
>Captured queries were:
>SELECT "model_forms_c

Re: MOSS Award to Django

[Markus Holtermann]

>From my point of view the major non-functional difference is the interaction 
>with a client in *some way*. While a celery task runs without any form of 
>client, a channels method would mostly do that. Picture the following example:

A user uploads an image. This could happen through the common request-response 
cycle. When the upload is done the server creates a celery task to generate a 
bunch of thumbnails and returns a http response. At this point the image is 
already available online but the thumbnails aren't. Every client could start a 
websocket connection through channels to get notified once a thumbnail is 
available. This notification is send through a server side callback called by 
the celery task.

/Markus


On December 16, 2015 2:45:49 PM GMT+10:30, Curtis Maloney  
wrote:
>On 16/12/15 12:05, Ben Liyanage wrote:
>> And, beyond that, there are plenty of non-critical tasks that
>> applications could easily offload until after a response has been
>> sent - like saving things into a cache or thumbnailing
>> newly-uploaded images.
>>
>> http://channels.readthedocs.org/en/latest/concepts.html#concepts
>>
>> I mean this example sounds like celery to me.  You don't want an
>image
>> to maybe have a thumbnail generated.  And you have no return value to
>> the client when the thumbnail is generated.
>
>There are certainly some cases, AIUI, where channels can obviate the 
>need for Celery... like sending emails, or thumbnailing uploaded image,
>
>and so on.
>
>However, given the different reliability profiles, there's still room 
>for both.
>
>--
>Curtis

-- 
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 https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/6037EBAB-C6F1-4A22-A632-A89812B53A4B%40markusholtermann.eu.
For more options, visit https://groups.google.com/d/optout.

Re: MOSS Award to Django

[Markus Holtermann]

On December 16, 2015 6:01:58 PM GMT+10:30, Shai Berger  
wrote:
>On Wednesday 16 December 2015 08:08:59 Markus Holtermann wrote:
>> From my point of view the major non-functional difference is the
>> interaction with a client in *some way*. While a celery task runs
>without
>> any form of client, a channels method would mostly do that. Picture
>the
>> following example:
>> 
>> A user uploads an image. This could happen through the common
>> request-response cycle. When the upload is done the server creates a
>> celery task to generate a bunch of thumbnails and returns a http
>response.
>
>But here is Ben's point: Why would you introduce an additional moving
>part 
>here (Celery), when the Channels documentation specifically mentions
>this as a 
>use-case?

Because my "generate a thumbnail" might me some video decoding or another long 
running process that would block possible further requests, or simply because I 
could easier reuse that particular task in other parts of the website as well.

>If I get it right -- Curtis' description is spot-on; some tasks will
>still 
>need Celery, Channels will take care of many others.

For me it's more a question of "is a client directly involved".

/Markus

-- 
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 https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/D484E906-05BC-4959-A786-9F80BFF41B5C%40markusholtermann.eu.
For more options, visit https://groups.google.com/d/optout.

Re: Removing Unique Together Field

[Markus Holtermann]

Hey Bill,

I added a patch for the ticket Tim already linked to. This solves the
problem for RemoveField operations, RenameField shouldn't be a
problem since the generation of AlterUniqueTogether and
AlterIndexTogether are already based on renamed fields. Tests welcome ;)

/Markus

On Mon, Oct 27, 2014 at 11:48:43AM -0700, Tim Graham wrote:

Hi Bill,

Yes, I believe this is a valid issue. I think it was reported in
https://code.djangoproject.com/ticket/23614

Tim

On Monday, October 27, 2014 12:32:10 PM UTC-4, Bill Prin wrote:


Hi all,

I wasn't sure which mailing list to put this on, so I cross-posted it with
django-core-mentorship. Apologies if this isn't the right forum.

I stumbled across an issue when removing a field from a unique_together
constraint. Specifically, when you remove a field, and remove it from the
unique_together constraint, the makemigration command creates a migration
that first removes the field, then removes the constraint. However, it puts
the operations in the wrong order which creates an error.

I've had this problem in Django 1.7, and I just checked out master 1.8
from github and reproduced the issue.

Here I am removing a field question3 from a model, as well as removing it
from the unique_together constraint (question1, question2, question3).

operations = [
migrations.RemoveField(
model_name='question',
name='question3',
),
migrations.AlterUniqueTogether(
name='question',
unique_together=set([('question1', 'question2')]),
)
]

The problem is that the field is gone when the unique together constraint
is altered, creating this problem:

django.db.models.fields.FieldDoesNotExist: Question has no field named
u'question3'

This is trivial to fix by reversing the order of the operations. I did
search the bug tracker and mailing lists and did not find the issue, but
again, apologies if I didn't look in the right place.

The reason I'm posting here instead of just submitting an issue is because
I would love to get involved in contributing to core, and this seems like a
really easy bug to get my hands dirty with. However, given that I'm not
super familiar with the project, before I dove into it I thought I would
run it by the mailing lists to verify that I'm not missing something, and
also that if I do make a pull request to fix it, it will be accepted.
Thanks for any advice!

Bill



--
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/09170b1f-5ba9-40e5-be16-6f2926f4c908%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


--


pgpK98m7kpLay.pgp
Description: PGP signature

Re: sys.exit(1) from makemigrations if no changes found

[Markus Holtermann]

I like the general idea, but I slightly disagree with "As the command is 
instructed to make migrations, not making any is the error case.". Yes, 
grep works that way but I thing this are two different use cases. I think 
makemigrations on a project without any changes in the models' database 
representation shouldn't exit with RC>0. I'd prefer to have the return code 
either only set on dry-run or explicitly when using -e/--exit. I'm in favor 
of 2. or 3.

/Markus

On Wednesday, October 29, 2014 8:44:31 AM UTC+1, Marc Tamlyn wrote:
>
> I agree number 1 is fine. For most general interaction with the command 
> users won't notice.
>
> Marc
> On 29 Oct 2014 02:04, "Andrew Godwin" > 
> wrote:
>
>> I'm actually fine with option 1 - always exiting with a status code if no 
>> migrations are found. Since the status code does nothing useful at the 
>> moment, I don't see any backwards compatibility issues, and as long as it's 
>> a suitably small patch, it should be fine.
>>
>> (As for being surprising compared to grep, there are many other commands 
>> with different exit codes one could draw parallels to; I'm not sure being 
>> consistent with a very different utility is a worthwhile cause).
>>
>> Andrew
>>
>> On Tue, Oct 28, 2014 at 6:22 PM, Tim Heap > 
>> wrote:
>>
>>> Hi all,
>>>
>>> I have created a ticket for this (
>>> https://code.djangoproject.com/ticket/23728) but I would like some 
>>> input before I work on it. I will copy the content of the ticket below for 
>>> ease of reading:
>>>
>>> It would be very useful for continuous deployment, testing, commit 
>>> hooks, and other applications if django-admin makemigrations signaled 
>>> via an exit code if any migrations were found. Commits in projects could be 
>>> rejected if migrations were outstanding, continuous deployment systems 
>>> could fail the build on outstanding migrations, and potentially other uses. 
>>> No more would hasty commits break things when developers forgot to make 
>>> migrations!
>>>
>>> Changes to the code to make this happen are easy enough, but I am unsure 
>>> how the command should behave. The grep unix utility is a example to 
>>> copy. Under normal operation, grep always exits 0 unless an error 
>>> happens, regardless of whether it found any matches. Invoking grep with 
>>> the -q/--quiet flag causes grep to be silent, not printing anything, as 
>>> well as exiting 0 if matches are found and 1 if nothing is found.
>>>
>>> I am proposing django-admin makemigrations should exit with 1 (or 
>>> anything non-zero) if no migrations to make were found, or exit 0 if 
>>> migrations to make were found. As the command is instructed to make 
>>> migrations, not making any is the error case.
>>>
>>> I am unsure how this new functionality should be selected by the user 
>>> when invoking makemigrations. The options I see are:
>>>
>>>1. Enable this always. This is very simple to implement and easy to 
>>>understand. Good unixy tools use error codes extensively to signal 
>>> errors. 
>>>This may be surprising behaviour when compared to grep though, and 
>>> breaks 
>>>backwards compatibility in a minor way.
>>>2. Enable this when the --dry-run flag is enabled. Now this flag can 
>>>be used to check for migrations that need to be created both visually 
>>> via 
>>>the printed text, and composed in shell commands.
>>>3. Add a new flag -e/--exit (or similar). The sole purpose of this 
>>>flag would be to exit with 1 when no migrations were found. This could 
>>> be 
>>>combined with --dry-run to just check for migrations that need to be 
>>>made.
>>>4. Add a new flag -q/--quiet that copies the behaviour of greps 
>>>-q/--quiet flag: silences output and exits with 1 when no migrations 
>>>were found. This duplicates functionality though, as logging can be 
>>>silenced using -v0 already.
>>>
>>> My personal preference is for option 2. I was surprised when enabling 
>>> --dry-run did not signal its result via the exit code. 3 would be the 
>>> cleanest and most composable option, as 4 could be emulated using -ev0.
>>>
>>> I will implement this change using 2, unless other people have opinions 
>>> on the matter.
>>>
>>> Regards,
>>> Tim
>>>
>>> -- 
>>> 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/92203dcb-a775-4c17-a831-97d01ce8af3c%40googlegroups.com
>>>  
>>> 
>>> .

Add ability to show the migration plan (#23359)

[Markus Holtermann]

Hey folks,

A few weeks ago I opened a ticket 
(https://code.djangoproject.com/ticket/23359) to add the ability to show a 
migration plan similar as listing all migrations within a project 
(manage.py migrate --list). After some discussions on IRC and on the first 
pull request (https://github.com/django/django/pull/3116) we realized that 
there might even be more use cases, e.g. to output all migration files as a 
dot file to generate a graph 
(https://github.com/django/django/pull/3116#issuecomment-53565075). That's 
when I opened a second pull request that moves the existing "--list" and 
the new "--plan" option from the "migrate" command to a "showmigrations" 
command.

Any suggestions on which way I should follow, integrate in "manage.py 
migrate" (pull request 3116: https://github.com/django/django/pull/3116) or 
add a new dedicated command "manage.py showmigrations" (pull request 3153: 
https://github.com/django/django/pull/3153)?

/Markus

-- 
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/f8bdabfc-f005-4e8e-b1d9-0b69dfdedd82%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Django security releases issued: 3.0.1, 2.2.9, and 1.11.27

[Markus Holtermann]

Thanks for checking and asking!

On Python 2, the email address with "i without dot" isn't a valid email address 
according to the EmailValidator and thus shouldn't be in your database in the 
first place.

Cheers,

/Markus 

On Wed, Dec 18, 2019, at 11:23 AM, Sam Willis wrote:
> Hi,
> 
> It looks to me like this has introduced a slight behaviour difference 
> with 1.11 on python 2.7 than on 3.x:
> 
> https://github.com/django/django/commit/f4cff43bf921fcea6a29b726eb66767f67753fa2#diff-e840e362abe9e625eee52d91897400bdR36
> 
> The release notes don't indicate what the difference in behaviour is 
> between python 2 and 3.
> 
> I'm trying to follow the change and test cases but it looks like if you 
> have two users 'm...@example.org' and 'mık...@example.org' (which is 
> highly unlikely anyway to happen legitimately) neither can reset their 
> password anymore on py2?
> 
> See: 
> https://github.com/django/django/commit/f4cff43bf921fcea6a29b726eb66767f67753fa2#diff-d4ef44f66fdc7127c6178eee0fdcaf57R697
>  
> 
> I'm guessing this was found after the similar GitHub vulnerability was found?
> 
> Thanks for the hard work!
> 
> On Wednesday, December 18, 2019 at 9:23:35 AM UTC, Mariusz Felisiak 
> wrote:Details are available on the Django project weblog: 
> > 
> > https://www.djangoproject.com/weblog/2019/dec/18/security-releases/ 
> > 
> 
>  -- 
>  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 view this discussion on the web visit 
> https://groups.google.com/d/msgid/django-developers/5cde448c-7631-472f-857f-168bd872fe3e%40googlegroups.com
>  
> .

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/d7e03a11-10c3-4f7b-9932-2a9e0497e318%40www.fastmail.com.

Re: New Merger nomination.

[Markus Holtermann]

Thanks James for summarizing the process. Thanks Mariusz for the suggestion.

Let's make it official, then. I'd like to nominate Claude Paroz 
(https://github.com/claudep) to be a Merger for the Django project and ask my 
fellow Technical Board members to cast their votes.

Claude has been contributing to Django for almost a decade. His roles in i18n 
related matters has been a constant help to the project. Providing Claude with 
commit access to github.com/django/django and giving him the MERGER role will 
allow him to continue his work and maintain an up to date translation base in 
the project, especially in the days leading towards a release.

I vote +1

/Markus 

On Sat, Mar 14, 2020, at 10:05 AM, Claude Paroz wrote:
> Hey! Thanks for suggesting me as a merger!
> 
> However, I'd like to clarify that I'm not requesting this commit bit. 
> If the project thinks it's good that I get it, I'll accept that and do 
> my best to use it as the new DEP suggests. If not, I can certainly 
> continue to contribute as I've done in the past.
> 
> Cheers,
> 
> 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 view this discussion on the web visit 
> https://groups.google.com/d/msgid/django-developers/a3ae8f2e-b6a8-4d93-8c62-954dc1646b3d%40googlegroups.com
>  
> .

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/7f64628f-ac87-4992-9663-d651848a18a7%40www.fastmail.com.

Re: Proposal to deprecate NullBooleanField (and remove in Django 4.0)

[Markus Holtermann]

Makes sense. We'd have the deprecation shims around for a while anyway.

/Markus

On Tue, Mar 17, 2020, at 11:10 AM, Carlton Gibson wrote:
> Ok, that’s pretty quick and conclusive, so let’s progress. Thanks all. 
> 
> On Tue, 17 Mar 2020 at 11:00, Shrawan Poudel  wrote:
> > +1 from me
> > 
> > On Tue, Mar 17, 2020 at 3:00 PM Adam Johnson  wrote:
> >> +1 from me.
> >> 
> >> On Tue, 17 Mar 2020 at 07:59, Aymeric Augustin 
> >>  wrote:
> >>> Hello,
> >>> 
> >>> I'm inclined to Accept as well.
> >>> 
> >>> -- 
> >>> Aymeric.
> >>> 
> >>> 
> >>> 
>  On 17 Mar 2020, at 08:49, Carlton Gibson  
>  wrote:
>  
>  Hi all. 
>  
>  
>  https://code.djangoproject.com/ticket/31369
>  Proposes to deprecate NullBooleanField. 
>  
>  
>  https://code.djangoproject.com/ticket/29227 
>  Allowed BooleanField to be null=True. 
>  Introduced in Django 2.1. 
>  
>  
>  I'm inclined to Accept. 
>  Wonder if folks consider it a little too fast? 
>  (We could defer for 5.0.) 
>  
>  
>  Kind Regards,
>  
>  Carlton
>  
>  
>   -- 
>   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 view this discussion on the web visit 
>  https://groups.google.com/d/msgid/django-developers/02a4b01d-e47f-4092-826e-c0cfa074901f%40googlegroups.com
>   
>  .
> >>> 
> 
> >>>  -- 
> >>>  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 view this discussion on the web visit 
> >>> https://groups.google.com/d/msgid/django-developers/6353F843-B61D-4C50-8A45-98DAD860301A%40polytechnique.org
> >>>  
> >>> .
> >> 
> >> 
> >> -- 
> >> Adam
> 
> >>  -- 
> >>  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 view this discussion on the web visit 
> >> https://groups.google.com/d/msgid/django-developers/CAMyDDM3bCYzz3JMCVgXP1%2BmB56CCmTiHmw1ij%3Dbj_5aQSGWaZQ%40mail.gmail.com
> >>  
> >> .
> 
> >  -- 
> >  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 view this discussion on the web visit 
> > https://groups.google.com/d/msgid/django-developers/CAPD6JmmfPwGKjQ_Zjet0SENz3Rk26UhfRL9TrpX0Kxo7HdMWtA%40mail.gmail.com
> >  
> > .
> 
>  -- 
>  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 view this discussion on the web visit 
> https://groups.google.com/d/msgid/django-developers/CAJwKpyRU95YkyRYbyZi388GB-wx9EMjGOMRQ6-3-exS1s46%3Dyg%40mail.gmail.com
>  
> .

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/02c3cca0-ca87-4b56-a1ca-866b516a5e7d%40www.fastmail.com.

Re: Technical Board statement on type hints for Django

[Markus Holtermann]

Thanks for pushing this public, Adam. In the discussion I brought up these 
points.

I've been using static typing in Python for about 1.5 years now. Every now and 
then it's neat, but often enough I get annoyed by it. Either because I simply 
don't know how to use the tools at hand correctly or because there's something 
that's just not expressible via type annotations.

The DEP is indeed very much draft. It covers so much, for a rather young setup, 
that at this point, I would not accept it. Everything from it's mention of 
`@overload` is too complex and I'm not sure any of that API is stable enough to 
rely on it in Django.

What I could see Django doing is having type annotations that don't go beyond 
the stdlib support: e.g. `def foo(bar: str) -> Optional[int]` or `def 
foo(instance: models.Model) -> int:`. But far more complex constructs will 
eventually cause breakage and displeasure during development of and with Django.

Often enough at work there's situations where no one can figure out how to 
properly type-annotate something. We then end up with `# type: ignore` or not 
typing a function at all. That's technical dept that we'll hardly ever lose. 
And because it doesn't show up in any CI, it won't cause any issue. But that 
means, we'll eventually have everything type-ignored or heaps of function not 
typed at all. I do not want to see that in Django. If something can't be typed 
or the typing is wrong: `# type: ignore` shouldn't ever be used. At this point, 
I'd instead drop the typing that causes it.

The DEP kind of singles out mypy. As Adam already mentioned, there's about four 
type checkers out there. I wouldn't want Django to pick one and have special 
support for that. Instead, everything that would be special to one of them 
should be developed externally. Especially since these tools iterate quickly 
and change quickly. If a plugin were to be bundled with Django, we'd need to 
support it for 3 years. What when that tool changes the entire API (again, 
young scenery, high velocity).

With regards to the PR Carlton asked about 
(https://github.com/django/django/pull/12405), if that helps people to build 
tooling around Django, let's do it.

Cheers,

Markus

On Fri, Apr 17, 2020, at 11:41 AM, Adam Johnson wrote:
> So we in the technical board were a bit opaque and had our discussion 
> in private before Carlton posted our summary. Apologies for this. We'll 
> repeat the discussion in the open so you can see our reasoning.
> 
> On 4 March Carlton prompted for our input. I replied:
> 
> > My experience using types, so far:
> >  * I'm the author of flake8-no-types, the flake8 plugin for banning type 
> > annotations 😂 I wrote it whilst reviewing a client's code base which had 
> > type annotations, mostly added by PyCharm autocomplete, but no MyPy 
> > running. Running MyPy produced >1k errors. Eventually I actually fixed the 
> > errors rather than stripping the annotations and installing flake8-no-types 
> > - there was thankfully a lot of repetition in the errors.
> >  * I have a vague memory writing one open source PR using types but can't 
> > remember the project.
> >  * I'm a little confused keeping up with the various ways of declaring 
> > types, 'best practices", and which type checkers are out there (last I 
> > heard there are 4!?).
> > I agree that the tools are young, and evolving relatively quickly - both 
> > MyPy and the standard library. I'm not sure there's quite enough stability 
> > yet to roll types out across the whole of Django.
> > 
> > There's the risk that we end up in a chicken/egg stalemate where if no 
> > major Python project commits to being typed, types don't get enough 
> > adoption to progress. But I think there are enough popular projects, like 
> > Starlette, that are using them.
> > 
> > At current it does seem to be a vocal niche of developers who want them.
> > 
> > 
> > Yes it will make PR's harder to review, and definitely adds a barrier to 
> > contribution. Even relatively Pythonic Django-ey constructs like "accept 
> > anything with an as_expression method, or castable to a string" require 
> > quite a lot of type system knowledge to write correctly. On top of this the 
> > best practices seem to still be changing.
> > 
> > 
> > One extra benefit would be a little more clarity around Django API's. For 
> > example, I think a past mistake was allowing database expressions' 'params' 
> > to be *either* a tuple or list, which means casting everywhere (a bug for 
> > years in django-mysql: 
> > https://github.com/adamchainz/django-mysql/pull/558/files ). That said this 
> > is relatively low impact - the documentation often doesn't mention types at 
> > all and Python developers are used to checking things in a REPL.
> > 
> > I think accepting the current PR is okay. [the one for `__class_getitem__` ]
> > 
> > A next step could potentially be experimentally by providing type 
> > annotations in more limited scope projects. One that could work well is 

Re: New Merger nomination.

[Markus Holtermann]

I vote in favor of Claude becoming a MERGER.

Cheers,

Markus

On Thu, Apr 16, 2020, at 10:31 PM, charettes wrote:
> I cast my vote in favor of Claude's nomination as well.
> 
> Le jeudi 16 avril 2020 16:16:31 UTC-4, Adam Johnson a écrit :
> > This has fallen by the wayside, let's try restarting.
> > 
> > As Carlton points out, Claude hasn't been merging in code without others 
> > reviewing it. But as I understand it is useful to keep translations moving 
> > that he can merge in his or others' (accepted) PR's. It gets us to the 
> > minimum of three mergers, and Claude has stated he's willing to do his best 
> > in the role of merger. And I hope Claude can help inform us what we can do 
> > to make i18n more smooth.
> > 
> > I nominate Claude as a merger.
> > 
> > Technical board, please post your votes.
> > 
> > On Thu, 19 Mar 2020 at 07:59, Carlton Gibson  wrote:
> >> I don't know if this got blocked in the now-obsolete use of cognates of 
> >> "commit"? 
> >> 
> >> > The Merger role is not just a new name for "committer". If Claude is 
> >> > appointed a Merger, he will be forbidden to do what you are saying -- 
> >> > a Merger cannot push their own contributions directly into Django! 
> >> 
> >> Claude hasn't, and wouldn't, "commit" directly to Django here. He's always 
> >> opened a 
> >> PR with the translations updates, which has then been reviewed, and which 
> >> then, yes, he has 
> >> merged, and forward/backported as necessary — which IS the Merger role. 
> >> (IIUC)
> >> 
> >> In the Merger role, Claude would also be able to approve and Merge other 
> >> PRs. 
> >> 
> >> Beyond this important translations case, we do need a third Merger, and I 
> >> cannot think of a better candidate. 
> >> (The two most active contributors are Claude and Simon, and Simon cannot 
> >> serve as a Merger because of his 
> >> role on the Technical Board.) 
> >> 
> >> I would ask the Technical Board to proceed with the nomination, as, bar 
> >> the loose language, I think it is in line with the DEP. 
> >> 
> >> Kind Regards,
> >> 
> >> Carlton
> >> 
> 
> >>  -- 
> >>  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-d...@googlegroups.com.
> >>  To view this discussion on the web visit 
> >> https://groups.google.com/d/msgid/django-developers/14af7b19-bcd3-4462-9e25-606f30ff6eda%40googlegroups.com
> >>  
> >> .
> > 
> > 
> > -- 
> > Adam
> 
>  -- 
>  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 view this discussion on the web visit 
> https://groups.google.com/d/msgid/django-developers/c13e6529-0e75-4e04-8ea6-501982420504%40googlegroups.com
>  
> .

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/ce2d7acb-8ad8-4d79-b76b-643499ca745a%40www.fastmail.com.

Re: Progress report: DEP 10 implementation

[Markus Holtermann]

Thanks for the summary, James.

As one of the IRC group contacts, here's the proposal for what happens to the 
cloaks on Freenode:

- Right now there's a @django/committer/$name cloak. We'd abandon that cloak.

- Instead, every DSF member can apply for a @django/member/$name cloak by 
getting in touch with one of the IRC group contacts (namely apollo13 and 
myself, MarkusH) and pointing them to their name on the DSF member list. I'm 
not entirely sure yet how we would do the verification. Maybe by asking for the 
IRC handle when people become IRC members?

- To ensure we have moderators in place for every #django-* channel we'd also 
introduce the @django/moderator/$name cloak. Each DSF member can apply for that 
cloak. It will give cloak holders "voice" privileges in #django-* channels. One 
needs to show "regular activity" in at least one official channel to become a 
moderator.

- Former @django/committer/$name holders will be migrated to 
@django/member/$name unless they reach out to an IRC group contact before (or 
after, but that's double the work 😉).

With regards to the #django-core IRC channel, we'll figure out how to delete 
it. People in there, expect to be kicked out 🙂.

Cheers,

Markus

On Tue, Apr 21, 2020, at 5:34 AM, James Bennett wrote:
> Last month the process of adopting DEP 10 -- new governance for the
> Django project -- was completed:
> 
> https://www.djangoproject.com/weblog/2020/mar/12/governance/
> 
> As a result, we are now in the implementation stage. Although there
> will almost certainly be other items that pop up on the to-do list,
> here's a quick status update on what has been done so far, and what
> still needs to be done.
> 
> Some of these items require particular permissions; for example, I
> believe I currently have the necessary permissions to handle the PyPI
> configuration change, and I know I have the necessary permissions to
> create a page on djangoproject.com for listing the recipients of the
> initial grant of "Django Core Developer" status, but some others --
> particularly closing mailing lists, and IRC-channel bureaucracy -- I
> don't have access for, so consider this message a call to anyone who
> *does* have those permissions to get in touch and coordinate on
> getting them done.
> 
> 
> * DONE -- Create a Mergers group for the main Django repository
> * DONE -- Remove commit access for the main Django repository from the
> former "Django Core" team
> 
> * IN PROGRESS -- DSF Board develops infrastructure for running a
> Technical Board election
> * IN PROGRESS -- Restrict PyPI package-upload access to Releasers
> * IN PROGRESS -- Add page on djangoproject.com listing recipients of
> "Django Core Developer" title
> * IN PROGRESS -- Update Django documentation to describe DEP 10 governance
> 
> * TODO -- Close django-core mailing list
> * TODO -- Close django-technical-board mailing list
> * TODO -- Close #django-core IRC channel
> * TODO -- Remove or change Django "committer" cloak on Freenode IRC
> * TODO -- DSF Board to create a process for granting "Django Core
> Developer" title beyond initial DEP 10 grant
> * TODO -- First DEP 10 election of Technical Board
> 
> -- 
> 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 view this discussion on the web visit 
> https://groups.google.com/d/msgid/django-developers/CAL13Cg9vj6qGbnR9Zj6inYNsRTv1Orbvn-CkWBmtCFRDoLTxGA%40mail.gmail.com.
>

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/0ddfcd81-7495-46c6-973b-47d8c5c3df4d%40www.fastmail.com.

Re: Generate JWTs with Django

[Markus Holtermann]

Nice work, Claude!

However, dealing with JWTs, and especially verifying them is notoriously hard 
and fragile. Frankly, I think I'd rather see smaller libraries do one job and 
do it well, than having Django implement an incomplete JWT spec. As far as I 
can tell, only HS256 signing/verification is implemented, but nothing else, 
right?

Cheers,

Markus

On Wed, Apr 22, 2020, at 3:38 PM, Adam Johnson wrote:
> Hi Claude
> 
> JWT's are indeed popular for API's. I think if Django was being created 
> "from the ground up" today, JWT's would be a no-brainer to include, so 
> it seems reasonable to add some support.
> 
> I've had a look at the PR, and yes it is indeed a small amount of code 
> - and thanks for the documentation.
> 
> Have you got any data on how often encrypted vs. non-encrypted JWT's 
> are used? Personally I can't remember from the projects I've worked on 
> which format has been used.
> 
> Thanks,
> 
> Adam
> 
> On Wed, 22 Apr 2020 at 09:57, Claude Paroz  wrote:
> > For your information, I now added docs to the tentative patch:
> > 
> > https://github.com/django/django/pull/12728
> > 
> >  Claude
> > 
> >  Le 15.04.20 à 21:26, Claude Paroz a écrit :
> >  > Thanks Abhijeet for the pointer, I know there are some rather complete
> >  > JWT libs around, but my proposal is not about a complete package to
> >  > manage JWT in general.
> >  > It's rather some low level ability for Django to produce and decode
> >  > simple HS256 JWT. Then other third-party libs could build on that
> >  > ability to write more elaborate packages.
> >  > 
> >  > The main doubt I have about my proposal is whether HS256 JWTs are too
> >  > limited for most usages or in the contrary if they are appropriate for a
> >  > fair amount of use cases.
> >  > 
> >  > Claude
> >  > 
> >  > Le 15.04.20 à 21:13, Abhijeet Viswa a écrit :
> >  >> Hi,
> >  >>
> >  >> You might want check out django-restframework-simplejwt. It requires the
> >  >> Django Rest Framework. But, then again, if you are making an API, you'd
> >  >> already be using it.
> >  >>
> >  >> Regards,
> >  >> Abhijeet
> >  >>
> >  >> On Thu, 16 Apr, 2020, 00:39 Claude Paroz,  >  >> > wrote:
> >  >>
> >  >> Hi all,
> >  >>
> >  >> With the recent addition of the algorithm parameter to the
> >  >> signing.Signer class, it's now rather straightforward for Django to
> >  >> generate HS256 (non-encrypted) JSON Web Tokens.
> >  >> With a growing popularity of JS-client/Django server communications
> >  >> (DRF and al.), I think there might be some interest for Django to be
> >  >> able to generate and decode such tokens. For any other types of JWTs
> >  >> which generally require access to a cryptography module, we can
> >  >> point users to third-party libs like PyJWT (the docs should be clear
> >  >> about that).
> >  >>
> >  >> I made a proof-of-concept PR (docs missing) here:
> >  >> - https://github.com/django/django/pull/12728
> >  >>
> >  >> What people here think about that proposal?
> >  >>
> >  >> 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 view this discussion on the web visit 
> > https://groups.google.com/d/msgid/django-developers/87ddf575-0756-b99e-51d8-99de1b258c21%402xlibre.net.
> 
> 
> -- 
> Adam
> 
>  -- 
>  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 view this discussion on the web visit 
> https://groups.google.com/d/msgid/django-developers/CAMyDDM2x%3D%2BB0xM0YRauHxwDDm2ymxeGmYqYCVdOMJS94-F4Xdg%40mail.gmail.com
>  
> .

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/bb569a66-38d5-4165-8da9-fa0cd6a799da%40www.fastmail.com.

Re: [FEATURE] Allow squashmigrations to squash the whole project

[Markus Holtermann]

Have you considered to allow for multiple app_labels in the `squashmigrations` 
command, maybe together with a `--cross-app` flag, to specify the apps from 
which migrations should be squashed? That way we don't need to rely on paths at 
all, but can log up all migrations in question, based on the provided app 
labels.

Cheers,

Markus

On Tue, Apr 28, 2020, at 2:47 PM, Adam Johnson wrote:
> That's good, but unfortunately BASE_DIR is only a "pseudo setting." 
> It's something in the startproject template that's useful for building 
> file paths but nothing inside Django actually relies on it or checks 
> that it's set. Perhaps we should consider "promoting" it to a real 
> setting though, to make this easier. Still, that might be naive for 
> projects that bundle their dependencies in some way :/
> 
> (Slightly tangential - my post on BASE_DIR and its move to pathlib in 
> 3.1: 
> https://adamj.eu/tech/2020/03/16/use-pathlib-in-your-django-project/ )
> 
> On Tue, 28 Apr 2020 at 13:36, Javier Buzzi  wrote:
> > Correct. Im adding that functionality currently -- im taking the VERY naive 
> > approach of looking at BASE_DIR and if the app is not in there, its foreign 
> > to the project. Some insight or better ideas to this would be appreciated.
> 
> >  -- 
> >  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 view this discussion on the web visit 
> > https://groups.google.com/d/msgid/django-developers/f202a4bb-1d7b-4c85-9695-f4ef3b996c3c%40googlegroups.com
> >  
> > .
> 
> 
> -- 
> Adam
> 
>  -- 
>  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 view this discussion on the web visit 
> https://groups.google.com/d/msgid/django-developers/CAMyDDM2%3DSTi9pe3LyaYL4%2BLEu8ZcWCgcjynR5MvV30PJiTsoDQ%40mail.gmail.com
>  
> .

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/eaa8b320-15b9-43ab-b50c-3bb6a704898f%40www.fastmail.com.

Re: [FEATURE] Allow squashmigrations to squash the whole project

[Markus Holtermann]

But for isort one specifies the `known_first_party` and `known_third_party` 
packages. https://github.com/timothycrosley/isort#configuring-isort

At least I was under the impression that that's the only way how it decides 
where to place imports.

Cheers,

Markus

On Tue, Apr 28, 2020, at 9:41 PM, charettes wrote:
> It's notoriously hard to distinguish between first-party and 
> third-party apps but I know some package manage to do it relatively 
> well (e.g. isort).
> 
> Le mardi 28 avril 2020 14:32:13 UTC-4, Javier Buzzi a écrit :
> > To be kind to the user, absolutely! .. any idea on how to implement it O:)
> > 
> >> On Apr 28, 2020, at 2:29 PM, charettes  wrote:
> >> 
> >> Don't we need to prevent that from happening anyway? I guess we'd want to 
> >> prevent --crossapp=auth from working as well.
> >> 
> >> Le mardi 28 avril 2020 13:50:54 UTC-4, Javier Buzzi a écrit :
> >>> To do that we need to know which apps are part of your project, and which 
> >>> are not. Otherwise you'll be squashing "django.contrib.auth" as an 
> >>> example, and you're not going to have a fun time at that..
> >> 
> >>  -- 
> >>  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-d...@googlegroups.com.
> >>  To view this discussion on the web visit 
> >> https://groups.google.com/d/msgid/django-developers/ca814e82-9258-40eb-afed-82edb0bc29c8%40googlegroups.com
> >>  
> >> .
> > 
> 
>  -- 
>  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 view this discussion on the web visit 
> https://groups.google.com/d/msgid/django-developers/8af08a8f-4f4d-4fef-8daa-e3743a1f8468%40googlegroups.com
>  
> .

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/3f95c379-9958-4ec9-8a14-aa0243f0ecb8%40www.fastmail.com.

Re: Ticket #25236: Remove ifequal from the template language

[Markus Holtermann]

Yes please! Nice catch and followup :)

Cheers,

Markus

On Mon, May 4, 2020, at 4:08 PM, Jon Dufresne wrote:
> Hi,
> 
> I'd like to raise this topic for renewed discussion. I think it is time 
> to begin deprecating the obsolete template tags. So +1 for removal.
> 
> I had all but forgotten about the {% ifequal %} template tag and then 
> eventually stumbled across it doing unrelated work. Upon rediscovering 
> it as a practical duplicate of {% if %}, I thought I'd help out Django 
> by deprecating it for eventual removal so that we're back to "one -- 
> and preferably only one -- obvious way to do it". I created the PR to 
> begin the deprecation here: https://github.com/django/django/pull/12851
> 
> We're now coming up on 10 years since Django 1.2 was released with the 
> smart if template tag. Projects and third party apps have had a 
> generous extended time to update their code.
> 
> For projects that don't follow Django releases in detail, they may not 
> be aware that the {% ifequal %} tag is obsolete and so have not had any 
> motivation to change. Adding a deprecation warning may help such 
> projects to understand they should update their templates.
> 
> For projects that find it is a burden to update, they've had 10 years 
> to do so. I think adding more time isn't what they need at this point. 
> The actual upgrade can be mostly automated with sed (I could even put a 
> recommended command in the release notes). So the update doesn't need 
> to be very time consuming.
> 
> While perhaps we agree leaving old code around can mostly go unnoticed, 
> technical debt has subtle ways of showing up. For example, time was 
> spent by me rediscovering this feature exists and wondering why there 
> are two way to write {% if ... %} (this could happen to other 
> contributors studying the template tag system). Time has been spent on 
> this mailing list discussing what to do with old unused code. Its tests 
> -- which mostly don't matter at this point -- run on every PR and in 
> local environments. If there is ever an attempt at an internal 
> refactoring of the template code, the ifequal tag will need to be 
> considered and maintained. And so on.
> 
> On Sun, Aug 9, 2015 at 12:37 PM Collin Anderson  wrote:
> > Hi All,
> > 
> > I really like the "don't use this on new code, but there's no rush in 
> > replacing it" category. I think that's really important to have that in a 
> > project that's this old. I think it would be great to minimize the amount 
> > required changes that need to be done.
> > 
> > Thanks,
> > Collin
> > 
> 
> >  -- 
> >  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/2ddf20f1-af1a-47c1-b07c-669818846b53%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 view this discussion on the web visit 
> https://groups.google.com/d/msgid/django-developers/CADhq2b5%3D3A03OjPTGa7mUgm-7braWgJwLUU_xW5pFJrgPP6Uow%40mail.gmail.com
>  
> .

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/6f2a7ca0-f223-4b24-8851-5fe37db3e89a%40www.fastmail.com.

Re: Django Version 3.2 Roadmap

[Markus Holtermann]

Hi Carlton,

thank you. The proposal looks good to me. +1

Cheers,

Markus

On Wed, May 13, 2020, at 2:51 PM, Carlton Gibson wrote:
> Hi all. 
> 
> I've prepared a draft of the Roadmap for Django 3.2 here: 
> 
> https://code.djangoproject.com/wiki/Version3.2Roadmap
> 
> Following the established release cadence, Django 3.2 will be due in 
> April 2021. 
> 
> The key dates are these. 
> 
> `
> = ==
> January 14, 2021 Django 3.2 alpha; feature freeze.
> 
> February 18 Django 3.2 beta; non-release blocking bug fix freeze.
> 
> March 18 Django 3.2 RC 1; translation string freeze.
> 
> April 1 Django 3.2 final
> = ==
> `
> 
> In accordance with DEP 10, I'd like to ask the Technical Board to 
> review this when able, and approve it or suggest adjustments if needed.
> 
> Thanks. 
> 
> Kind Regards,
> 
> Carlton
> 
> 
> 
> 
>  -- 
>  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 view this discussion on the web visit 
> https://groups.google.com/d/msgid/django-developers/d19d3303-34aa-4e87-b867-04e7b48f81a5%40googlegroups.com
>  
> .

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/78f612d8-58e6-4f46-b371-c079d503f826%40www.fastmail.com.

Re: Clear all filters

[Markus Holtermann]

I tend to agree with Adam.

>From a UI/UX perspective, the location where the "Clear all filters" button 
>is, as well as the wording, suggest to me that it's only the filters on the 
>right side. The search query, while technically filtering the query set, 
>doesn't seem like a filter in the UI.

I'd potentially argue otherwise if the search field was in the filter box on 
the right.

Additionally, looking at it from the back-end, search terms and filters have 
nothing in common except for the queryset.

Cheers,

Markus


On Mon, May 18, 2020, at 11:10 AM, Mariusz Felisiak wrote:
> > I disagree Mariusz. I would NOT expect this. The "Clear all filters" button 
> > is grouped with the filters, visually separate from the search and sort 
> > controls. It's a very legitimate use case to clear the filters and maintain 
> > the search or sort, and quite a common workflow when trying to find a 
> > particular object.
> 
> The idea of this feature was to remove all filters and *search 
> criteria* in one click (see the ticket description[2]). The first 
> proposition was to put this link in actions [2], but I proposed moving 
> it to filters. I'm not sure if link for clearing only filters is still 
> necessary (and it wasn't the intention of reporter), we can remove this 
> feature if it's misleading. Link to the right of the search box ("X 
> total") already removes the entire query string, so ...
> 
> > Additionally, I see that the link only preserves the _popup=1 query param. 
> > if users have extended their admin views with any extra query params, they 
> > will also be wiped, which is less than helpful. I know I have extended the 
> > admin with extra params before e.g. to control the queryset.
> 
> Link to the right of the search box ("X total") that was added in 2005 
> [3] do the same. We should probably use `add_preserved_filters`.
> 
> [1] https://code.djangoproject.com/ticket/27888
> [2] https://github.com/django/django/pull/12351#issuecomment-577415747
> [3] 
> https://github.com/django/django/commit/9dda4abee1225db7a7b195b84c915fdd141a7260
> 
>  -- 
>  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 view this discussion on the web visit 
> https://groups.google.com/d/msgid/django-developers/ed3810c9-bb86-4e05-97dd-4818efa1617c%40googlegroups.com
>  
> .

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/a366340a-9b8e-4ac5-9478-10380680de99%40www.fastmail.com.

Re: What happens if a Fellow has a holiday?

[Markus Holtermann]

Enjoy your time off. I'll keep my eyes open for PRs.

Cheers,

Markus

On Thu, Jun 4, 2020, at 2:09 PM, charettes wrote:
> Happy to review help as well.
> 
> Enjoy your well deserved time off!
> 
> Le jeudi 4 juin 2020 06:47:57 UTC-4, Carlton Gibson a écrit :
> > Hi all. 
> > 
> > Short answer is we don't really know, since we never take holidays. 🙂
> > 
> > I though am having a much needed week off from tomorrow, to be back on the 
> > 16th. 
> > 
> > Mariusz will need assistance as available *Approving changes*, from Claude 
> > (our third merger) and the Technical Board, who can also Approve PRs. 
> > Mostly that's not needed for contributor PRs, but Mariusz makes a lot of 
> > his *own PRs* as he's working, and those do need approval.
> > Both these points by DEP 10.
> > 
> > To facilitate this I have added the Django Technical Board GitHub team to 
> > the django/django repo, with the non-write "Triage" role. 
> > In this context, mostly this allows Mariusz to ask the TB by team handle 
> > for a review. 
> > (I trust this is OK.) 
> > 
> > 3.1b1 is due on the 15th. We can delay that but... 
> > 
> > Please can I ask the 6 of you to be aware that you might be needed. 
> > Thanks. 
> > 
> > 
> > Kind Regards,
> > 
> > Carlton
> > 
> > 
> > 
> > 
> > 
> > 
> > 
> > 
> 
>  -- 
>  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 view this discussion on the web visit 
> https://groups.google.com/d/msgid/django-developers/b566bbf5-a470-4700-8fed-4b9edc6d7c11%40googlegroups.com
>  
> .

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/ad9a8c62-d0ba-4ce3-ab4b-8fde0ba7c594%40www.fastmail.com.

Re: Unsolicited mentorship requests

[Markus Holtermann]

Interesting. Because I got a similar messages this morning, one on Twitter and 
one on LinkedIn. Here's my response:

> Hi {{ name }}. Thank you for reaching out. Unfortunately, I'm not available 
> for outside help at this time. If you need help working on Django projects 
> would like to suggest the django-users mailing list, the discussion forum, or 
> the IRC channel as documented on djangoproject.com/community/ . If you are 
> looking for mentoring working on Django itself, please use the 
> django-core-mentorship mailing list 
> (https://docs.djangoproject.com/en/dev/internals/mailing-lists/#django-core-mentorship)
>  or the discussion forum. Cheers and stay safe. Markus

Maybe that helps?

Cheers, Markus

On Mon, Jun 8, 2020, at 7:02 PM, Daniele Procida wrote:
> Elena Williams wrote:
> 
> >Just want to bring this up in case it's a "Thing"[tm] now, that I have
> >missed: this last week I've had 3 different non-Australia non-female-
> >presenting individuals who I don't know solicit me privately on social
> >media for personal Django "mentorship". Frankly it's made me feel pretty
> >uncomfortable, but I've never been approached like this so rather than
> >just ruminating I thought I should just ask around if any one is
> >familiar with this happening? It's just several in a short window of
> >time seemed like a weird pattern.
> 
> That seems unusual, to me at least.
> 
> I also get contacted regularly about all kinds of things, but not in 
> such a pattern.
> 
> Is there something off about the tone, or the assumptions?
> 
> One never really knows where one's name has been shared, and what 
> expectations have been formed. I have in the past felt bothered by such 
> things without always being able to put my finger on why.
> 
> Asking for personal mentorship without an introduction or explanation 
> certainly seems a bit weird, and I would not like it either.
> 
> Regards,
> 
> Daniele
> 
> -- 
> 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 view this discussion on the web visit 
> https://groups.google.com/d/msgid/django-developers/20200608170210.534891312%40mail.gandi.net.
>

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/3eeb180d-9f36-4d37-b051-93eaebb44337%40www.fastmail.com.

Re: The blacklist / master issue

[Markus Holtermann]

I'd be in favor of changing blacklist/whitelist into something that makes 
sense. In many cases, that's going to be context dependent, but often 
blocklist/allowlist will work.

With regards to "master" as the development branch on GitHub, I'd like to pick 
whatever GitHub eventually goes with as a "new default".

Cheers,

Markus

On Mon, Jun 15, 2020, at 9:56 PM, Daniele Procida wrote:
> Tom Carrick wrote:
> 
> >I don't think there is an easy answer here, and I open this can of worms
> >somewhat reluctantly. I do think Luke is correct that we should be
> >concerned with our credibility if we wrongly change this, but I'm also
> >worried about our credibility if we don't.
> 
> There are plenty of black-something terms in English that are both 
> negative and have nothing whatsoever to do with race. The black and the 
> dark are those things that are hidden and sinister, as contrasted with 
> those that are in the light and open to scrutiny (black magic, dark 
> arts, black legs, blackguards, blackmail, etc).
> 
> I think it would look pretty silly to confuse meanings that refer to 
> what's shadowy and obscure with things that have racial overtones, and 
> I think we should steer well clear of that. It's not at all like 
> metaphors such as master/slave. 
> 
> If we made such a change and tried to justify it on the grounds of a 
> connection between race and the word "black" in those terms, we'd be 
> rightly laughed at.
> 
> 1000 neckbeards would immediately come out of the woodwork having done 
> some basic web searches going 'neeer neeer neeer, the Django Software 
> Foundation overflowing with snowflakes who think that "blacklist" means 
> [etc etc etc]', and who has the stomach for that? 
> 
> Even choosing to do it on the basis of the potential for offence seems 
> to be a fairly flimsy argument.
> 
> On the other hand, we can do whatever the hell we like. 
> 
> We don't have to justify anything to anyone. If we want to change words 
> in *our* framework, it's absolutely nobody's business but our own.
> 
> If black members of the DSF or the community are disheartened that the 
> word "black" gets to refer to so many negative things and are bothered 
> when they see them in Django, then that alone is sufficient 
> justification. 
> 
> If we want a reason for changing "blacklist" (or whatever), it's that 
> people in our community said they would feel better about it and asked 
> to have it changed. 
> 
> Acknowledging how someone feels about something and acting because you 
> care about their feelings seems to be a respectful thing to do.
> 
> "We did it because we felt like it" is an utterly unanswerable justification.
> 
> The DSF has credibility because the software is first rate, the 
> foundation is well-governed and the community is an international 
> example of decency and kindness. Things like this become credible 
> because the DSF chooses to do them - it's not the other way round.
> 
> Daniele
> 
> -- 
> 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 view this discussion on the web visit 
> https://groups.google.com/d/msgid/django-developers/20200615195628.938692561%40mail.gandi.net.
>

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/64e1b503-289c-4119-acfc-51fe6537addb%40www.fastmail.com.

Re: The blacklist / master issue

[Markus Holtermann]

First things first:

I'm glad, Django changed master/slave and blacklist/whitelist to more 
appropriate and adequate terms. Naming things is hard. And just because 
somebody came up with a name decades ago doesn't mean it can't — or even 
shouldn't — be changed. Especially when there are more descriptive alternatives.

I'm glad, Django is in the position to take a stance for a more inclusive 
language in technology and against decades old, racist, terminology.

I'm glad, Django, as several other software projects out there, picked up on 
the Black Lives Matter protests happening in the US and around the globe.

I'm glad, Django has a Code of Conduct 
(https://www.djangoproject.com/conduct/) and a community where racist behavior 
is not tolerated.

---

Alexander, since you brought up the news, I'm sure you're aware that the 
BlackLivesMatter protests are happening around the globe and are not only in 
the US. Racist behavior exists pretty much everywhere, certainly in the US and 
Germany.

I'm a young, white man, from Germany. I have never experienced any racist 
behavior towards me. But I'm fairly certain that there are plenty of people on 
this list who have.

We're still living in a society where white men are privileged in many ways. If 
I can stand in solidarity and support of black colleagues, friends, and members 
of the Django community, by reexamining and addressing language choices that 
have ugly backgrounds to their history, I'm glad!

Markus

On Sun, Jun 21, 2020, at 10:10 PM, Alexander Lyabah wrote:
>  Daryl, that is very strange, that you bring it here now.
> 
> > One of Django's strengths is that decision making is *not* polluted by one 
> > strong opinion, a whim by a marketing department, or trend-following. 
> 
> renaming whitelist and blacklist is exactly what is in trend right now. 
> I understand that not everybody are following US-news, but if you 
> google "blacklist blm" you will find, how big the trend is, actually.
> 
> Also, thank you sharing those link, but can you plz elaborate more, why 
> do you bring those and what do you what to proof by sharing those 
> links, so when I read those links again, I know on what point I should 
> focus more. 
> 
> Thank you for being involved in this conversation.
> 
>  -- 
>  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 view this discussion on the web visit 
> https://groups.google.com/d/msgid/django-developers/267f6649-a434-47fb-93c9-880b594d213ao%40googlegroups.com
>  
> .

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/cd9101a8-f93d-4ba7-b6e8-f97f8bc57d3b%40beta.fastmail.com.

Re: f-strings again.

[Markus Holtermann]

I've been one of those who previously were against adding them to Django. 
Mostly, because I wasn't used to them and didn't see their value. But more 
importantly, because I was worried about unintended security issues they could 
cause. Why the latter is still present, I've think the vulnerability vectors 
are fairly small. Hence:

+1 to allow them in PRs that add new code or adjust existing code
-1 on PRs who's primary focus is to change either % or .format() to use 
f-strings

/Markus

On Tue, Jul 21, 2020, at 11:24 AM, Tom Carrick wrote:
> I'm also +1, I find f-strings easier to read in most cases. You can go 
> overboard -  and I probably do - but I don't think the guard against 
> unreadable f-strings is to ban them outright.
> 
> One small negative to % formatting for me is that I sometimes get 
> confused for a second about whether something is interpolated in the 
> code or if they're placeholders for sql params or logging calls. But I 
> don't see a reason to change any of the current ones because of that.
> 
> Cheers,
> Tom
> 
> On Tue, 21 Jul 2020 at 10:55, Dave Vernon  wrote:
> > +1, I'd happily help on any PR with this (it would be my first!).
> > 
> > Kind Regards,
> > 
> > Dave
> > 
> > Springbourne Tech Limited
> > M: +44(0) 79 2107 6483 
> > W: www.springbourne-tech.com
> > 
> > 
> > 
> > 
> > *—
> > This E-Mail and its contents are confidential, protected by law and legally 
> > privileged.  Only access by the addressee is authorised.  Any liability (in 
> > negligence, contract or otherwise) arising from any third party taking any 
> > action or refraining from taking any action on the basis of any of the 
> > information contained in this E-Mail is hereby excluded to the fullest 
> > extent of the law.  In the event that you are not the addressee, please 
> > notify the sender immediately.  Do not discuss, disclose the contents to 
> > any person or store or copy the information in any medium or use it for any 
> > purpose whatsoever.*
> > 
> > 
> > 
> > 
> > On Tue, 21 Jul 2020 at 09:43, Nick Pope  wrote:
> >> Hi,
> >> 
> >> So I'm in favour of using f-strings, but agree that there are places where 
> >> they are not appropriate.
> >> 
> >> I am also against bulk updates in this case as mentioned in my previous 
> >> comment 
> >> . I 
> >> don't think we should exclude replacing .format() with f-strings on a 
> >> case-by-case basis, however, where performance is a concern.
> >> 
> >> Thanks for your initial documentation, Carlton. Am wondering whether we 
> >> should be more explicit about the pros and cons of each to help people 
> >> make the correct decision? Here are my thoughts:
> >> 
> >> %-formatting:
> >> 
> >> + Simple to use printf-style familiar to all.
> >> + Default (can be changed 
> >> ) 
> >> style used internally by the logging module, e.g. logging.info('Message 
> >> with %s.', value)
> >> − Much less flexibility for formatting, see pyformat.info.
> >> 
> >> ``.format()``:
> >> 
> >> + Useful for interpolating a stored template string, e.g. from a database, 
> >> which isn't possible with f-strings.
> >> − Worst performance due to method call.
> >> − Much more verbose, makes code less readable.
> >> 
> >> f-strings:
> >> 
> >> + Better performance than other methods due to dedicated FORMAT_VALUE 
> >>  opcode.
> >> + Allows for embedding more complex expressions, e.g. f'Hello 
> >> {user.get_full_name()}'
> >> + Much more concise, makes code more readable.
> >> − Cannot be used if string must be translated.
> >> − Complex expressions can get out of control. A sensible balance needs to 
> >> be struck.
> >> 
> >> Regarding performance, here are some simple numbers:
> >> 
> >> python -m timeit -s 'x="test"' 'f"{x}"'
> >> 2000 loops, best of 5: 11.8 nsec per loop
> >> $ python -m timeit -s 'x="test"' '"%s" % x'
> >> 1000 loops, best of 5: 39.1 nsec per loop
> >> $ python -m timeit -s 'x="test"' '"{}".format(x)'
> >> 500 loops, best of 5: 76.1 nsec per loop
> >> 
> >> I think it is probably also worth updating the documentation added in this 
> >> commit 
> >> .
> >>  It isn't that xgettext doesn't support f-strings... It does:
> >> 
> >> $ echo "_('Hello %s') % user.username" | xgettext --language=python 
> >> --omit-header --output=- -
> >> #: standard input:1
> >> #, python-format
> >> msgid "Hello %s"
> >> msgstr ""
> >> $ echo "_('Hello {}').format(user.username)" | xgettext --language=python 
> >> --omit-header --output=- -
> >> #: standard input:1
> >> msgid "Hello {}"
> >> msgstr ""
> >> $ echo "_('Hello {name}').format(name=user.username)" | xgettext 
> >> --language=python --omit-header --output=- -
> >> #: standard input:1
> >> #, python-brace-format
> >> msgid "Hello {name}"
> >> msgstr ""
>

Re: Status of 3.1 release blockers.

[Markus Holtermann]

Thank you for summarizing our IRC discussion, Mariusz. To be clear, the problem 
occurs during the upgrade process where more than 1 server is involved. That 
might be the case in small deployments with just 2 servers, where the time of 
two Django versions running simultaneously is likely small, or on huge 
deployments of the course of days or weeks, when a staged rollout occurs.

Cheers, Markus

On Fri, Jul 31, 2020, at 11:28 AM, Mariusz Felisiak wrote:
> Markus reported a release blocker #31842 
>  related with running an 
> app on multiple servers with different versions of Django (3.0.x or 
> 3.1). Signatures created on servers with Django 3.1 are not valid on 
> Django 3.0, it's not only about signing.loads()/dumps but also about 
> sessions etc. (see #27468 
> ). We have several 
> possible approaches:
>  * revert commits related with #27468,
>  * change the default hashing algorithm to SHA-1,
>  * add the new setting for the default hashing algorithm,
>  * add the "algorithm" parameter to signing.dumps()/loads() (PR13260 
> ) and ignore the rest of 
> the problem (it's probably not an option),
>  * add the new setting "MIN_DJANGO_VERSION" and change the default 
> hashing algorithm if it's 3.0 or less.
>  * ... (ideas are welcome)
> Best,
> Mariusz
> 
> -- 
> 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 view this discussion on the web visit 
> https://groups.google.com/d/msgid/django-developers/2a3d706d-6f78-406e-b7a9-3bba3ea9b7e6n%40googlegroups.com
>  
> .

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/d8d56bc4-98a4-460b-ac8c-3b194b11daa4%40beta.fastmail.com.

Re: Status of 3.1 release blockers.

[Markus Holtermann]

No, it won't move the problem to 3.2. The problem is that 3.0 only knows about 
sha1. 3.1 and later know about sha1 and sha256. Meaning, any >=3.1,<4.0 version 
can decode and verify signed data from 4.0 and before.

Cheers

Markus
 
On Fri, Jul 31, 2020, at 12:08 PM, Raffaele Salmaso wrote:
> On Fri, Jul 31, 2020 at 11:47 AM Carlton Gibson 
>  wrote:
> > Add the new setting default to sha1.
> > Raise a DeprecationWarning unless it’s set to sha256 (so folks can opt-in 
> > to the future.)
> > Remove setting, and change default to sha256, when 4.0?
> > 
> > Does that sound right? (Grrr.)
> I think this just move the migration problem from 3.2 to 4.0. 
> What about the other way: add a migration setting set to new algorithm, 
> so who really need sha1 can opt-in to old algorithm?
> 
> -- 
> | Raffaele Salmaso
> | https://salmaso.org
> | https://bitbucket.org/rsalmaso
> | https://github.com/rsalmaso
> 
> -- 
> 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 view this discussion on the web visit 
> https://groups.google.com/d/msgid/django-developers/CABgH4Jt0xXzXrFO8vAFFbF_zabF6xhFGnnTS1rJi_iWAT9fJRg%40mail.gmail.com
>  
> .

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/1b35a40d-c3e3-4aab-a856-078f2efad7c4%40beta.fastmail.com.

Re: Status of 3.1 release blockers.

[Markus Holtermann]

Can we come up with a way that we have the settings variable around for now, 
only to allow transitioning, and then add it as a proper feature in 3.2.

As for the feature, I think we could choose a path like passlib does: A list of 
2 (n>=1) algorithms. The first one will be used for signing, and all of them 
for verification. We could then limit the set of options to sensible algorithms 
(or put some algorithms on a blocklist, such as md5). But I think that's 
nothing we should add the day before the final release.

Cheers,

Markus

On Mon, Aug 3, 2020, at 8:48 AM, Mariusz Felisiak wrote:
> It seems that adding DEFAULT_HASHING_ALGORITHM setting is an acceptable 
> solution, we have one remaining question: Do we keep the setting around?
>  1. we can treat DEFAULT_HASHING_ALGORITHM as a transitional setting, 
> limit its values to `sha1` and `sha256`, and deprecate it immediately. 
> Florian said: *"From a security perspective I wonder if we should limit 
> this that the existing sha1 and the new sha256 algos. We really don't 
> ever want anyone to put md5 there and it is really just a transitional 
> setting.", "...setting this to sha256, running with it and then 
> changing it to sha512 will be a hard cut. There will be no migration 
> path like there would be for sha1. Imo that limits the usefulness of 
> such a setting for long term usage and makes it questionable if we want 
> to support such usage."*
>  2. we can treat DEFAULT_HASHING_ALGORITHM as a new feature and allows 
> any secure hash algorithm supported by hashlib. Simon said: *"**It does 
> add one more setting but it feels like having this configurable project 
> wide will be a plus as it will allow the ecosystem to rely on it and 
> hopefully make audit of large Django application a bit easier when 
> having specific hashing requirements.".*
> Personally I think we should choose the first option because it's 
> safer. 
> 
> *We're delaying the 3.1 release until tomorrow.*
> 
> Best,
> Mariusz
> 
> 
> -- 
> 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 view this discussion on the web visit 
> https://groups.google.com/d/msgid/django-developers/023a0518-a58c-48c6-8b36-9d5fb7a7c108n%40googlegroups.com
>  
> .

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/17636c67-cdb5-4cf9-bb95-b10b8cc0885d%40www.fastmail.com.

Re: Set up autolinks on Django's GitHub repositories

[Markus Holtermann]

Hi Sage,

thank you for the suggestion. There's already autolinking setup for 
`ticket-123`. I'm happy to add another one which would be a bit briefer. But if 
this is done, the contribution documentation needs to be updated as well.

/Markus

On Mon, Aug 3, 2020, at 8:06 AM, laym...@gmail.com wrote:
> Hi folks,
> 
> I came across this feature on GitHub today:
> https://docs.github.com/en/github/administering-a-repository/configuring-autolinks-to-reference-external-resources
> 
> In short, it adds autolinks to external resources (e.g. our issue 
> tracker) by referencing them using a prefix in GitHub comments or 
> commits. So, instead of using Markdown to manually link to a ticket, we 
> can just use the prefix followed by the ticket number, e.g. *TR-123* 
> and GitHub will automatically convert it to a link.
> 
> Currently, we use the # character as a convention to refer to the 
> tickets. However, this conflicts with the use of # on GitHub which 
> automatically links to PRs (and issues if enabled). As a result, 
> commits that refer to a ticket whose number is also a valid PR number, 
> incorrectly link to the PR. Here's an example: 
> https://github.com/django/django/commit/5d4b9c1cab03f0d057f0c7751862df0302c65cf9
> 
> As you can see, the commit message links to PR#12990 which actually 
> isn't relevant. This also generates noise in the PR itself: 
> https://github.com/django/django/pull/12990. I think that can be 
> misleading to new contributors.
> 
> By using the autolinks, we can properly link the reference to the 
> tickets. Sadly, we can't replace GitHub's # autolinks. So, we need to 
> create a new prefix. This has some downsides, though:
>  * It breaks the current convention of using # to refer to tickets.
>  * The prefix must only contain letters, numbers, or -:/#
>  * The prefix is 3 characters minimum, so this means commit messages 
> will be at least 2 characters longer than with the current convention.
> However, considering the benefits:
>  * No more incorrect links to irrelevant PRs.
>  * No more noise in PRs from irrelevant commits.
>  * Clickable ticket numbers in commits that take you to the tickets.
>  * Quick linking to tickets in GitHub comments (no need to use 
> Markdown).
>  * Less confusion to new contributors.
> I think it's worth it.
> 
> What do y'all think? If we're to agree upon this, I guess we need to 
> come up with the prefix. I don't have any preference; as long as it 
> makes sense, I'm in.
> 
> Oh, and one more thing: maybe we can also set up a prefix for PRs to 
> easily differentiate between the two from now on. Here are some 
> proposals:
>  * *TR-1234* for TRac tickets, and *PR-5678* for PRs.
>  * *TR#1234* for TRac tickets, and *PR#5678* for PRs.
> And maybe we can set up another for DEPs, but that may not be 
> necessary...
> 
> Regards,
> Sage
> 
> -- 
> 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 view this discussion on the web visit 
> https://groups.google.com/d/msgid/django-developers/e070dd97-0d22-4566-a605-867141f7e0aan%40googlegroups.com
>  
> .

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/0f9ddf24-b903-4bf1-9b27-bc73353b1957%40www.fastmail.com.

Re: Anonymous access to the forum

[Markus Holtermann]

Thanks for bringing this up, Claude. I'll look into it.

Cheers,

Markus

On Tue, Aug 18, 2020, at 9:14 AM, Claude Paroz wrote:
> Hello,
> 
> Am I the only one or did Google closed anonymous access to Google groups?
> Could it be a setting in the group config?
> 
> In my opinion, it is not acceptable for the project if accessing the
> Django group posts require authentication.
> 
> If someone has more information about that change, that would be great.
> 
> Claude
> -- 
> www.2xlibre.net
> 
> -- 
> 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 view this discussion on the web visit 
> https://groups.google.com/d/msgid/django-developers/45961852-2b29-e763-23f9-f55aca70e074%402xlibre.net.
>

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/40cc7a4a-954f-4b46-8725-0f74aba6c701%40www.fastmail.com.

Re: Anonymous access to the forum

[Markus Holtermann]

Thanks Adam. I did set the value to "Anyone on the web" again (it had that 
value already). And since that didn't change anything I went public: 
https://twitter.com/m_holtermann/status/1295635386820157440

What _does_ work, is viewing threads directly, only showing a list of threads 
doesn't work for me as an anonymous user.

Cheers,

Markus

On Tue, Aug 18, 2020, at 10:31 AM, Adam Johnson wrote:
> You're not the only one, I also get redirected to login when visiting 
> the group URL in a "private mode" window: 
> https://groups.google.com/group/django-developers
> 
> I did some research and found there's a "New Google Groups" update. I 
> think this has done it. Links:
>  * Beta announcement post: 
> https://gsuiteupdates.googleblog.com/2020/03/new-google-groups-beta.html
>  * General release post: 
> https://gsuiteupdates.googleblog.com/2020/05/new-google-groups-generally-available.html
>  * List of changes: https://support.google.com/a/answer/9687393 (I 
> couldn't spot anything related to removing anonymous access)
> I checked on another group I'm an admin for and in settings I found 
> "Who can see group" with options "Group members" and "Anyone on the 
> web". Perhaps Google didn't migrate this setting and we need to reset 
> it to "Anyone on the web"? Can one of the admins for django-users and 
> django-developers check?
> 
> On Tue, 18 Aug 2020 at 08:14, Claude Paroz  wrote:
> > Hello,
> > 
> > Am I the only one or did Google closed anonymous access to Google groups?
> > Could it be a setting in the group config?
> > 
> > In my opinion, it is not acceptable for the project if accessing the
> > Django group posts require authentication.
> > 
> > If someone has more information about that change, that would be great.
> > 
> > Claude
> > -- 
> > www.2xlibre.net
> > 
> > -- 
> > 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 view this discussion on the web visit 
> > https://groups.google.com/d/msgid/django-developers/45961852-2b29-e763-23f9-f55aca70e074%402xlibre.net.
> 
> 
> -- 
> Adam
> 
> -- 
> 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 view this discussion on the web visit 
> https://groups.google.com/d/msgid/django-developers/CAMyDDM1GgzzLnLx4GSiDfvuEWkdO9TS6Uw0%3DXzkfxso%2BBaaAWg%40mail.gmail.com
>  
> .

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/cd206b2e-d837-4cf0-8416-e0bdfe3d27cc%40www.fastmail.com.

Re: Technical Board Decision Needed: Admin append_slash behaviour.

[Markus Holtermann]

Thanks you for bringing this up, Carlton. And thanks Jon for tackling the 
issues.

I concur with what has been said so far. Especially what James said, that there 
are so many places where one possibly/maybe/theoretically could come up with 
timing attacks. Mitigating the difference in response code behavior (302 vs 
404) seems like a sensible idea.

But adding the append slash behavior to the Admin seems unnecessary. Especially 
given the example Adam brought up. Maybe you want to post that approach on the 
corresponding ticket, Adam, and close it as wontfix?

Cheers,

Markus

On Thu, Jan 7, 2021, at 5:26 PM, Florian Apolloner wrote:
> 
> 
> On Thursday, January 7, 2021 at 2:16:57 PM UTC+1 carlton...@gmail.com wrote:
> > 1. Add the catch-all view to admin to stop the unauthenticated probing, as 
> > per the Security Teams initial idea, but not the AdminSite.append_slash 
> > option.
> > 2. Don't even add the catch-all, and close the ticket as wontfix. 
> 
> I think the catch-all view is certainly a worthwhile addition, it is a 
> low hanging fruit that makes fast probing if auth.user is installed 
> impossible.
> 
> > * It SEEMS to me that the catch-all view does serve it's purpose as as the 
> > AdminSite.admin_view decorator redirects all non-staff requests equally to 
> > login (whether they exist or not, because the catch-all view exists.) This 
> > is prior to any per-view timing variation. (I think 🙂)
> 
> Technically you could already mount a timing attack because url 
> resolving is not constant time, the first matching view wins :þ
> 
> 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 view this discussion on the web visit 
> https://groups.google.com/d/msgid/django-developers/03910826-32d4-44c9-a3d5-a35f984c05e7n%40googlegroups.com
>  
> .

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/a19773d6-4482-45b6-aaf0-08f08626b398%40www.fastmail.com.

Re: Revisiting Python support for after Django 3.2 LTS

[Markus Holtermann]

I think I need to go through all proposed options a few more times to 
understand their differences and implications.

But what about a more pragmatic approach: Django supports the currently 
supported Python versions at any given time. Except for our LTS versions, which 
would never drop support. That means, a Django 2.2 might need to get fix in 
2.2.x to support e.g. Python 3.11. But if Python support for 3.8 is dropped, 
why not drop it from Django' non-LTS versions. Where "drop" is meant as a , we 
won't add fixes to support an old Python version, and we won't add new features 
from a new Python version that's around. But if a new Python version requires a 
fix, let's back port it.

Cheers,

Markus

On Wed, Jan 27, 2021, at 4:22 PM, Carlton Gibson wrote:
> OK... urgh. I don't think there's a perfect answer here. 
> 
> As you say Tim, assuming the "support unless EOL before the Django 
> version's EOL"  we end up dropping the Python version before the LTS, 
> which is going to be just as "premature" as we have now, but for the 
> x.0. 
> 
> If I've not counted wrong (again) the 4.2 LTS, for example, due April 
> 2023, would drop Python 3.8 and 3.9, which have until Oct 2024 and 2025 
> to run. 
> 
> So we'd be trading extra life here for probably more complaints there. 
> 
> I've played around with various variations of the cut-off date without 
> any real ground being made. 
> 
> Thus, we probably need to stick as we are, in the main. 
> 
> A last option would be to say that the x.0 will support one extra older 
> version after the LTS, in cases like this where the otherwise dropped 
> version is supported for the whole lifetime of the x.0 release. 
> 
> That I think would look like this, assuming we backport support for new 
> versions within the mainstream support period: 
> 
> 4.0: 3.7, 3.8, 3.9, 3.10
> 4.1: 3.8, 3.9, 3.10, 3.11
> 4.2 LTS : 3.8, 3.9, 3.10, 3.11, 3.12
> 
> 4.2 is in danger of taking 3.13 as well, but that's released after 4.2 
> leave mainstream support.
> It's akin for what we did for Django 2.2 and Python 3.9
> That's independent of whether we keep support for 3.7 a bit longer. 
> 
> Having looked it through now, I think, fully, that's my final thought. 
> I'd need to think about the __exact wording, but I hope the idea is clear.
> 
> I take Claude's point about contributing but, for me, the desire to 
> support slightly more versions if we can is for beginners, picking up a 
> couple of year old laptop, with SOME version of Python on it, and being 
> able to get going, with hopefully the latest version. I appreciate they 
> can install an older version, but it's hard enough to get started 
> without hitting subtle version changes. I'd like to support that 
> use-case as best we can. 
> 
> The current policy begins, "Typically...". I'd suggest supporting 
> Python 3.7 for Django 4.0 is merely leveraging that. 🙂
> 
> We should decide. I'd be +1 to maintain the current policy but keep 3.7 
> support for Django 4.0, dropping it at Django 4.1. 
> 
> Thanks all, and especially you Tim for taking the time to explain and 
> explore the options. 
> C.
> 
> 
> 
> On Tuesday, 26 January 2021 at 22:00:31 UTC+1 timog...@gmail.com wrote:
> > Looking at this again, I'm not sure it would be six versions. Carlton's 
> > suggested policy has the effect of dropping a lot of Python versions right 
> > before the LTS since it's supported for 3 years. For example, in Django 5.2 
> > LTS, I think it's incorrect that Python 3.10 and 3.11 would be supported 
> > since their support expires in Oct 2026 & 7, before Django 3.2's expiration 
> > in April 2028)? The current policy means we have Django LTS's supporting 
> > some Python's well after they expire. I never liked that aspect of it. 
> > Anyway, the decision won't affect my life.
> > On Tuesday, January 26, 2021 at 5:32:50 AM UTC-5 Mariusz Felisiak wrote:
> >> Hi y'all,
> >> 
> >> I think we should keep the current policy. There is never a good time 
> >> to drop support for anything and extending support especially for Python 
> >> 3.7 will end with more exceptions in the future. Current policy is really 
> >> patronizing and with the new Python release schedule we can reach 6 
> >> supported versions of Python for every LTS. I would make it even more 
> >> aggressive :) It's not only about the maintenance burden but also about 
> >> new features and syntax, we have tickets waiting 2-3 years until Python X 
> >> becomes the minimal Python supported by Django. My 2 cents 🤷
> >> 
> >> Best,
> >> Mariusz
> 
> -- 
> 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 view this discussion on the web visit 
> https://groups.google.com/d/msgid/django-developers/ef691a05-1a1a-434f-bd0c-56b6f5d8a027n%40googlegroups.com
>  
>

Re: The blacklist / master issue

[Markus Holtermann]

Hi all,

Reviving an old topic. GitHub has by now tooling in place to rename branches 
and keep open PRs in sync. In fact, if I were to change the `master` branch to 
`main`, GitHub tells me this:

Renaming this branch:
* Will update 158 pull requests targeting this branch across 112 repositories.
* Will update 1 branch protection rule that explicitly targets master.
* Will not update your members' local environments. 

I'd suggest to go through with this change and make the necessary changes to 
the CI / website.

Cheers,

Markus


On Tue, Jun 23, 2020, at 11:04 AM, Mark Bailey wrote:
> +1 on a good decision to make this change.
> 
> -- 
> 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 view this discussion on the web visit 
> https://groups.google.com/d/msgid/django-developers/1e3d742a-7f38-4258-a5a3-bfb01a333020o%40googlegroups.com
>  
> .

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/6fb9c6cc-39a6-4741-9d61-d03a44d9c477%40www.fastmail.com.

Re: The blacklist / master issue

[Markus Holtermann]

Thanks for the input, Matthias. That's useful to know. I'll make sure the 
change is announced.

Cheers,

Markus

On Thu, Feb 25, 2021, at 7:24 PM, Matthias Kestenholz wrote:
> Yes, please.
> 
> As a third party app developer I'll have to update a few GitHub 
> workflows and tox configurations (since I'm running testsuites against 
> the main branch too). It may be useful to announce this change on as 
> many channels as possible (mailing lists, the forum, as a news entry on 
> the Django website). Just an idea, this shouldn't be a blocker for 
> moving forward with this.
> 
> Thanks,
> Matthias
> 
> 
> On 24/02/2021 00:12, 'Adam Johnson' via Django developers (Contributions 
> to Django itself) wrote:
> > Yes, let's do it. I did it to my open source projects a couple weeks ago 
> > and everything has been smooth since. We'll need some find/replace for 
> > links in the main repo, on djangoproject.com <http://djangoproject.com>, 
> > and I imagine some other places.
> > 
> > On Tue, 23 Feb 2021 at 22:15, Kenneth  > <mailto:kennethl...@gmail.com>> wrote:
> > 
> > I agree. We should go ahead and do the switch
> > 
> > On Tue, Feb 23, 2021 at 11:57 AM Markus Holtermann
> > mailto:i...@markusholtermann.eu>> wrote:
> > 
> > Hi all,
> > 
> > Reviving an old topic. GitHub has by now tooling in place to
> > rename branches and keep open PRs in sync. In fact, if I were to
> > change the `master` branch to `main`, GitHub tells me this:
> > 
> > Renaming this branch:
> > * Will update 158 pull requests targeting this branch across 112
> > repositories.
> > * Will update 1 branch protection rule that explicitly targets
> > master.
> > * Will not update your members' local environments.
> > 
> > I'd suggest to go through with this change and make the
> > necessary changes to the CI / website.
> > 
> > Cheers,
> > 
> > Markus
> > 
> > 
> > On Tue, Jun 23, 2020, at 11:04 AM, Mark Bailey wrote:
> >  > +1 on a good decision to make this change.
> >  >
> 
> -- 
> 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 view this discussion on the web visit 
> https://groups.google.com/d/msgid/django-developers/81446dcd-e04c-3c28-91b5-a276a38baaf7%40feinheit.ch.
>

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/8caebe33-6b52-46f7-8f7b-b324474a546b%40www.fastmail.com.

Re: The blacklist / master issue

[Markus Holtermann]

Brief update on this.

The overall tracking pull request ist 
https://github.com/django/django/pull/14048/

* On 2021-03-03 at UTC morning, well migrate django/code.djangoproject.com and 
django/djangoproject.com

* Likely on 2021-03-09 we'll migrate django/django

Cheers,

Markus

On Thu, Feb 25, 2021, at 7:31 PM, Markus Holtermann wrote:
> Thanks for the input, Matthias. That's useful to know. I'll make sure 
> the change is announced.
> 
> Cheers,
> 
> Markus
> 
> On Thu, Feb 25, 2021, at 7:24 PM, Matthias Kestenholz wrote:
> > Yes, please.
> > 
> > As a third party app developer I'll have to update a few GitHub 
> > workflows and tox configurations (since I'm running testsuites against 
> > the main branch too). It may be useful to announce this change on as 
> > many channels as possible (mailing lists, the forum, as a news entry on 
> > the Django website). Just an idea, this shouldn't be a blocker for 
> > moving forward with this.
> > 
> > Thanks,
> > Matthias
> > 
> > 
> > On 24/02/2021 00:12, 'Adam Johnson' via Django developers (Contributions 
> > to Django itself) wrote:
> > > Yes, let's do it. I did it to my open source projects a couple weeks ago 
> > > and everything has been smooth since. We'll need some find/replace for 
> > > links in the main repo, on djangoproject.com <http://djangoproject.com>, 
> > > and I imagine some other places.
> > > 
> > > On Tue, 23 Feb 2021 at 22:15, Kenneth  > > <mailto:kennethl...@gmail.com>> wrote:
> > > 
> > > I agree. We should go ahead and do the switch
> > > 
> > > On Tue, Feb 23, 2021 at 11:57 AM Markus Holtermann
> > > mailto:i...@markusholtermann.eu>> wrote:
> > > 
> > > Hi all,
> > > 
> > > Reviving an old topic. GitHub has by now tooling in place to
> > > rename branches and keep open PRs in sync. In fact, if I were to
> > > change the `master` branch to `main`, GitHub tells me this:
> > > 
> > > Renaming this branch:
> > > * Will update 158 pull requests targeting this branch across 112
> > > repositories.
> > > * Will update 1 branch protection rule that explicitly targets
> > > master.
> > > * Will not update your members' local environments.
> > > 
> > > I'd suggest to go through with this change and make the
> > > necessary changes to the CI / website.
> > > 
> > > Cheers,
> > > 
> > > Markus
> > > 
> > > 
> > > On Tue, Jun 23, 2020, at 11:04 AM, Mark Bailey wrote:
> > >  > +1 on a good decision to make this change.
> > >  >
> > 
> > -- 
> > 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 view this discussion on the web visit 
> > https://groups.google.com/d/msgid/django-developers/81446dcd-e04c-3c28-91b5-a276a38baaf7%40feinheit.ch.
> >
> 
> -- 
> 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 view this discussion on the web visit 
> https://groups.google.com/d/msgid/django-developers/8caebe33-6b52-46f7-8f7b-b324474a546b%40www.fastmail.com.
>

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/dd0f1e1a-3e6b-4202-8c55-f0741b35f88e%40www.fastmail.com.

Re: The blacklist / master issue

[Markus Holtermann]

Hi all,

Mariusz renamed the branches this morning and merged the corresponding pull 
requests. Thank you!

Please let us know if you spot problems so they can be fixed.

Cheers,

Markus

On Tue, Mar 2, 2021, at 6:05 PM, Markus Holtermann wrote:
> Brief update on this.
> 
> The overall tracking pull request ist 
> https://github.com/django/django/pull/14048/
> 
> * On 2021-03-03 at UTC morning, well migrate 
> django/code.djangoproject.com and django/djangoproject.com
> 
> * Likely on 2021-03-09 we'll migrate django/django
> 
> Cheers,
> 
> Markus
> 
> On Thu, Feb 25, 2021, at 7:31 PM, Markus Holtermann wrote:
> > Thanks for the input, Matthias. That's useful to know. I'll make sure 
> > the change is announced.
> > 
> > Cheers,
> > 
> > Markus
> > 
> > On Thu, Feb 25, 2021, at 7:24 PM, Matthias Kestenholz wrote:
> > > Yes, please.
> > > 
> > > As a third party app developer I'll have to update a few GitHub 
> > > workflows and tox configurations (since I'm running testsuites against 
> > > the main branch too). It may be useful to announce this change on as 
> > > many channels as possible (mailing lists, the forum, as a news entry on 
> > > the Django website). Just an idea, this shouldn't be a blocker for 
> > > moving forward with this.
> > > 
> > > Thanks,
> > > Matthias
> > > 
> > > 
> > > On 24/02/2021 00:12, 'Adam Johnson' via Django developers (Contributions 
> > > to Django itself) wrote:
> > > > Yes, let's do it. I did it to my open source projects a couple weeks 
> > > > ago 
> > > > and everything has been smooth since. We'll need some find/replace for 
> > > > links in the main repo, on djangoproject.com 
> > > > <http://djangoproject.com>, 
> > > > and I imagine some other places.
> > > > 
> > > > On Tue, 23 Feb 2021 at 22:15, Kenneth  > > > <mailto:kennethl...@gmail.com>> wrote:
> > > > 
> > > > I agree. We should go ahead and do the switch
> > > > 
> > > > On Tue, Feb 23, 2021 at 11:57 AM Markus Holtermann
> > > > mailto:i...@markusholtermann.eu>> wrote:
> > > > 
> > > > Hi all,
> > > > 
> > > > Reviving an old topic. GitHub has by now tooling in place to
> > > > rename branches and keep open PRs in sync. In fact, if I were to
> > > > change the `master` branch to `main`, GitHub tells me this:
> > > > 
> > > > Renaming this branch:
> > > > * Will update 158 pull requests targeting this branch across 112
> > > > repositories.
> > > > * Will update 1 branch protection rule that explicitly targets
> > > > master.
> > > > * Will not update your members' local environments.
> > > > 
> > > > I'd suggest to go through with this change and make the
> > > > necessary changes to the CI / website.
> > > > 
> > > > Cheers,
> > > > 
> > > > Markus
> > > > 
> > > > 
> > > > On Tue, Jun 23, 2020, at 11:04 AM, Mark Bailey wrote:
> > > >  > +1 on a good decision to make this change.
> > > >  >
> > > 
> > > -- 
> > > 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 view this discussion on the web visit 
> > > https://groups.google.com/d/msgid/django-developers/81446dcd-e04c-3c28-91b5-a276a38baaf7%40feinheit.ch.
> > >
> > 
> > -- 
> > 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 view this discussion on the web visit 
> > https://groups.google.com/d/msgid/django-developers/8caebe33-6b52-46f7-8f7b-b324474a546b%40www.fastmail.com.
> >
> 
> -- 
> 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 view this discussion on the web visit 
> https://groups.google.com/d/msgid/django-developers/dd0f1e1a-3e6b-4202-8c55-f0741b35f88e%40www.fastmail.com.
>

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/6eadf150-3208-4300-bedb-c2b615e023f2%40www.fastmail.com.

Re: Proposal to add attribute 'step' to FloatField and DecimalField

[Markus Holtermann]

Hi Jacob,

That sounds like a sensible feature. Do you want to open a ticket and maybe 
implement it?

Cheers

Markus

On Wed, Mar 17, 2021, at 12:45 AM, Jacob Rief wrote:
> If someone wants to use the step attribute as provided by the HTML field
>  , she/he has to specify that using for instance
> FloatField(widget=NumberInput(attrs={'step': 0.5})).
> 
> Since the HTML standard offers a step attribute on input fields of type 
> number,
> from my point of view, this feature shall be reflected by Django's 
> FloatField and 
> optionally DecimalField rather than having to parametrize the widget.
> 
> Min- and max-values are already supported by the FloatField, so the step-value
> would make sense here as well. It furthermore would require to revalidate the
> step-value by Django's Form validation, rather than by HTML alone.
> 
> – Jacob
> 
> -- 
> 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 view this discussion on the web visit 
> https://groups.google.com/d/msgid/django-developers/9a35aa63-0d22-4353-8f58-70a181e05791n%40googlegroups.com
>  
> .

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/35ea5249-6c7d-44c6-8171-0730e0a660bd%40beta.fastmail.com.

Re: Default change password UX: area for improvements

[Markus Holtermann]

Hi Federico,

this is a good idea. Could you check if there's a ticket about this on 
https://code.djangoproject.com/ already, and if not, possibly open one. That 
would be much appreciated. Thank you!

Cheers,

Markus

On Mon, Jun 7, 2021, at 11:12 PM, Federico Capoano wrote:
> Hey everyone,
> 
> Given the following text in the user change page:
> 
> *Raw passwords are not stored, so there is no way to see this user’s 
> password, but you can change the password using this form.*
> *
> *
> Linking the change user password form using the word "this form" is on 
> the same level of links with "click here", which is notoriously bad UX 
> and I believe the django community is made of a lot of experts so there 
> shouldn't be the need to explain this here.
> 
> However, we can do better than just changing the link form, wouldn't it 
> be possible to add a link styled as a button?
> 
> Eg:
> 
> Raw passwords are not stored, so there is no way to see this user’s 
> password, but the password can be changed.
> 
> *Change the password*
> 
> BTW, this idea came from this issue: 
> https://github.com/openwisp/openwisp-radius/issues/265.
> We can easily fix it in our django app but I thought it may be good to 
> raise this here so we may fix it at the root instead.
> 
> Best regards
> Federico Capoano
> 
> -- 
> 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 view this discussion on the web visit 
> https://groups.google.com/d/msgid/django-developers/CAERYH6VUm-bRsHkY_1LX9TwpJvMW%2B-Eyqf0Uye6FL%2B_Pb_%3D%2BQw%40mail.gmail.com
>  
> .

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/c73670f4-9324-467b-9861-48fff9eb326a%40www.fastmail.com.

Re: The certificate for code.djangoproject.com expired on 7/4/2021.

[Markus Holtermann]

We had some intermittent connection issues over the last couple of hours: 
https://status.djangoproject.com/.  All should be fine again.

Cheers

On Sun, Jul 4, 2021, at 4:14 PM, chris.j...@gmail.com wrote:
> Maybe someone can file an issue about it to address the same thing 
> happening in the future. Perhaps here: 
> https://github.com/django/code.djangoproject.com/issues
> 
> --Chris
> 
> On Sunday, July 4, 2021 at 9:14:20 AM UTC-4 Jason Johns wrote:
> > Ahh, I see the issue.
> > 
> > This screenshot is for Summer of Code 2021, at 
> > https://code.djangoproject.com/wiki/SummerOfCode2021.  You can see the cert 
> > is not valid before 0431 eastern
> > 
> > Screen Shot 2021-07-04 at 9.10.01 AM.png
> > 
> > This screenshot is for https://docs.djangoproject.com/en/3.2/:
> > 
> > Screen Shot 2021-07-04 at 9.09.14 AM.png
> > 
> > Looks like the SoC URL cert didn't get applied before this morning, and 
> > users who tried to access that URL would have gotten Certificate Expired 
> > errors.
> > On Sunday, July 4, 2021 at 9:07:55 AM UTC-4 Jason Johns wrote:
> >> FWIW, a user at pyslackers said they got a 503 about the same time about 
> >> 50 minutes after Asif's initial message.  Then about two hours later 
> >> (about an hour before Adam's reply), someone else responded that they 
> >> weren't able to replicate.  Maybe there was a delay in applying the cert 
> >> rotation?  I'm not able to easily see when the cert was generated.
> >> 
> >> On Sunday, July 4, 2021 at 5:38:01 AM UTC-4 Adam Johnson wrote:
> >>> Hi Asif
> >>> 
> >>> I'm not seeing a problem - the certificate I get expires in October.
> >>> 
> >>> Screenshot 2021-07-04 at 10.36.15.png
> >>> 
> >>> Thanks,
> >>> 
> >>> Adam
> >>> 
> >>> On Sun, 4 Jul 2021 at 06:34, Asif Saif Uddin  wrote:
>  
>  Websites prove their identity via certificates, which are valid for a 
>  set time period. The certificate for code.djangoproject.com expired on 
>  7/4/2021.
>   
>  Error code: SEC_ERROR_EXPIRED_CERTIFICATE
>   
>  View Certificate
>  
>  https://code.djangoproject.com/wiki/SummerOfCode2021
>  
>  Asif
>  
>  -- 
>  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 view this discussion on the web visit 
>  https://groups.google.com/d/msgid/django-developers/539fc003-f4de-4dae-8ace-d5103c19f44en%40googlegroups.com
>   
>  .
> 
> -- 
> 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 view this discussion on the web visit 
> https://groups.google.com/d/msgid/django-developers/4ab92cf4-04e0-4e30-a088-ec13ce3bc3d9n%40googlegroups.com
>  
> .

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/081140f7-e09a-4c6c-b31d-c1a17320b976%40beta.fastmail.com.

Re: RSS access to Google groups?

[Markus Holtermann]

Hi Claude,

I think you're receiving everything because you're a moderator everywhere and 
they get everything they're moderating by default. I'd need to look into this a 
bit more. But I think there's a way to disable excess notifications.

Cheers,

Markus

On Fri, Aug 13, 2021, at 10:53 PM, Claude Paroz wrote:
> So I activated mailing list mode, and chose i18n/geodjango in the watch 
> list. I'm still receiving all forum messages by email, which is 
> evidently not an option. If I have to manually mute/exclude all other 
> categories, it will not be very practical either, as I would have to do 
> it again each time new topics appear. Any other "magical" solution ? 
> 
> Le vendredi 13 août 2021 à 18:57:16 UTC+2, carlton...@gmail.com a écrit :
> > Hey Claude. 
> > 
> > Here: 
> > 
> > https://forum.djangoproject.com/my/preferences/categories
> > 
> > You can set to watch particular categories (or just first posts in a thread 
> > or … ) 
> > 
> > C. 
> > 
> >> On 13 Aug 2021, at 18:24, Claude Paroz  wrote:
> >> 
> >> A question received privately: imagine someone wants to follow the 
> >> Internationalization topic by email, is it possible and how? There is a 
> >> Mailing list mode in the forum prefs, but then I guess that this will send 
> >> messages from all forum topics.
> >> 
> >> -- 
> >> 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 view this discussion on the web visit 
> >> https://groups.google.com/d/msgid/django-developers/d9fb0ba1-3dd9-47d9-9fb6-5cd1a633788cn%40googlegroups.com
> >>  
> >> .
> > 
> 
> -- 
> 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 view this discussion on the web visit 
> https://groups.google.com/d/msgid/django-developers/5464cff4-d6ef-4b35-851c-e081359b4738n%40googlegroups.com
>  
> .

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/0d0cbd91-09f3-437d-a84b-5c2125787544%40beta.fastmail.com.

Re: Proposal for a transaction.on_before_commit

[Markus Holtermann]

Hi Raphael,

This is funny. Just last week I looked into exactly the same thing for audit 
logging as well. Except that I'm writing multiple audit log events and want to 
batch them at the end of the transaction in a single bulk_create operation 
instead of a dozen save() calls.

I haven't gotten anywhere for now. But was considering the thread local 
approach as well. But then, thread locals and Django are not the nicest 
combination.

Maybe we can come up with an approach together?

Cheers

Markus

On Sun, Oct 10, 2021, at 3:55 PM, Raphael Michel wrote:
> Hi everyone,
>
> I've spent some days thinking about a use case we have internally where
> we want to create some database records automatically based on some
> other records, think e.g. of an audit log where whenever an instance of
> model X is changed, we want to create an instance of model Y as a log
> record. Of course, there are *lots* of ways and libraries that allow you
> to do this with Django, mostly somehow circling around overriding
> `save()` or using the `post_save` signal.
>
> However, we want to do this in an *aggregated* way, i.e. even if you
> add hundreds of model instances in the same transaction, we only want
> *one* new line in our audit log to be created. This is impossible with
> `save()` or `post_save` alone since we can't know which change is the
> "last" that should trigger the audit log to be created.
>
> I figured a perfect way to do this would be using `save()` or
> `post_save` to add the changed model instance to some kind of
> thread-local list, and then using `transaction.on_commit` to "schedule"
> the aggregation and create the log entries when all changes have been
> made. However, this obviously is not a good enough because `on_commit`
> runs *after* the `COMMIT` statement and thus we're not guaranteed that
> all log entries are persisted to the database.
>
> So I was wondering if there was potential for a
> `transaction.on_before_commit` that works just like
> `transaction.on_commit` except that it is executed before the `COMMIT`
> statement. I imagine there are lots of other possible uses as well and
> without looking into it much deeper, it seems easy enough to implement.
>
> Does anyone have opinions on whether or not this would be a good
> feature to add to Django? Unfortunately it doesn't seem possible to do
> this as third-party code (except if we were shipping entire database
> backends) so it would need to be an acceptable change to Django to be a
> viable option.
>
> Thanks
> Raphael
>
> -- 
> 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 view this discussion on the web visit 
> https://groups.google.com/d/msgid/django-developers/20211010155522.6489b86d%40amara.localdomain.

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/6cd73b6f-d445-4706-b42a-276ae99213d1%40beta.fastmail.com.

Re: Preparing Django code for the Black stable release

[Markus Holtermann]

There is https://github.com/MarkusH/django-migrations-formatter which I think 
holds everything that's necessary to make the migration writer create 
black-formatted output.

Cheers, Markus

On Wed, Oct 20, 2021, at 11:11 AM, 'Adam Johnson' via Django developers  
(Contributions to Django itself) wrote:
> The extension I added to the DEP may be a bit involved:
>
>> All code Django generates will also be Black-formatted (startproject,
>> migrations, inspectdb, etc.), at least if the user has Black installed.
>>
> But then again it may only need a few calls to black.format_str() in the
> right places.
>
> On Wed, 20 Oct 2021 at 10:37, Mariusz Felisiak 
> wrote:
>
>>
>> As you can see from this pull request in the Black code the first stable
>>> release is expected for January 2022:
>>> https://github.com/psf/black/pull/2529
>>>
>>> I think we can start prepare this great migrations of the Django code so
>>> we will be ready when Black 22.0 will be released and we can finally
>>> benefit from this change.
>>>
>>> We have now more than 2 months to work on this.
>>>
>>
>> Hi
>>
>> Do you have any specific steps in mind? I'm not sure how we need to
>> prepare. Implementation, as described in DEP 0008
>> ,
>> should be rather straightforward and I don't think anything needs to be
>> done in advance. We (Fellows and OPS team) should be able to implement it
>> within a few days.
>>
>> Best,
>> Mariusz
>>
>> --
>> 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 view this discussion on the web visit
>> https://groups.google.com/d/msgid/django-developers/81687d6f-2ea3-44b4-a9c8-fab71e4e0843n%40googlegroups.com
>> 
>> .
>>
>
> -- 
> 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 view this discussion on the web visit 
> https://groups.google.com/d/msgid/django-developers/CAMyDDM0kbb2aF%2BMK0GObXFm6pVrt%3DWMLsX1TcK6QyEHpDVBjeg%40mail.gmail.com.

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/07f0f742-c503-4f8b-81b4-33bda7f937bf%40beta.fastmail.com.

Re: Preparing Django code for the Black stable release

[Markus Holtermann]

That's wonderful news. Thanks for the info, Paolo!

Cheers,

Markus

On Sat, Jan 29, 2022, at 10:24 PM, Paolo Melchiorre wrote:
> Hi all,
>
> Black 22.1.0 has just been released
> https://github.com/psf/black/releases/tag/22.1.0
>
> It seems the time has come to put DEP 0008 into practice and "run
> Black on the entire Django code repository and make a single commit".
>
> Ciao,
> Paolo
>
> On Wed, Oct 20, 2021 at 10:52 PM Paolo Melchiorre  
> wrote:
>>
>> On Wed, Oct 20, 2021, 21:51 Mariusz Felisiak  
>> wrote:
>>>
>>>
 I was thinking we can start right now using black in a branch and see 
 which issue will show up and start fixing them.
>>>
>>>
>>> We don't want to merge multiple commits related to black. According to the 
>>> "Implementation" section in DEP 0008, we're going to run Black on the 
>>> entire Django code repository and make a single commit. Running black 
>>> should not encounter any issues …
>>
>>
>> Okay, I also hope the migration to Black will be this smooth.
>>
>> So now we just have to wait for 2022.
>>
>> Ciao,
>> Paolo
>>
>>
>
>
> -- 
> Paolo Melchiorre
>
> https://www.paulox.net
>
> -- 
> 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 view this discussion on the web visit 
> https://groups.google.com/d/msgid/django-developers/CAKFO%2Bx6dZAw7ftsGvJOV5crHazXLW4RST_t26JDHFcqA1uNXEA%40mail.gmail.com.

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/18da12b4-75f0-4f48-a9e5-1fbde5caa0e6%40beta.fastmail.com.