Re: Management of static assets

[Claude Paroz]

Le mercredi 22 avril 2020 17:22:02 UTC+2, Carlton Gibson a écrit :
>
> ...
> *Not sure* how much of this we need to pull into Django itself? 
> compressor, say, does the whole combine and compress thing well. If we pull 
> that in are we going to do the same for image optimization? Or pull in 
> Whitenoise? Or...? For a user just with contib.staticfiles, what's the very 
> next thing we could do that would make life easier? (i.e. is "I can't run 
> webpack" top of their list?) — What can we do better in core vs a 
> third-party app? — Is that just awareness, which is not a nothing? 
> Note the "not sure" — I think about this a lot, it's a big issue, but I 
> don't have a single answer: I've got what I do, and that works for me, but 
> I see lots of people doing different with success. 
>

I fully understand that it's not necessarily the role of Django to provide 
a full backed solution to management of assets, which is indeed changing 
quickly in some aspects.
However, I think that the problem now is that Django isn't aware of global 
project or app assets (they are just lines in templates), which means that 
third-party packages must provide their own different implementation of 
asset "objects". It does also mean that Django is helpless with regards to 
any management of static assets, typically in a case like subresource 
integrity.

My opinion is still the same, that we should add basic blocks of asset 
objects in Django core, giving ability to Django to offer basic services 
that are useful for most projects, while letting third party apps to build 
upon those "blocks" to give specific functionalities that need a quicker 
development pace than Django itself.

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/10528a3d-4838-4358-804b-3f1f258a57f3%40googlegroups.com.

Re: New Merger nomination.

[Aymeric Augustin]

Hello,

I trust Claude to act as a Merger as described in DEP 10. I vote in favor.

With apologies for the late answer!

-- 
Aymeric.



> On 21 Apr 2020, at 20:11, Andrew Godwin  wrote:
> 
> I also vote in favour of Claude becoming a Merger!
> 
> Andrew
> 
> On Tuesday, April 21, 2020 at 4:28:41 AM UTC-6, Markus Holtermann wrote:
> 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-d...@ <>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/15a11b73-d6dd-4ea4-af42-0919e75a5147%40googlegroups.com
>  
> 

Re: Deadlock bug in logging? Reproducible case

[Steven Mapes]

This is more an issue at the file system level and the hardware not being 
able to keep up rather than anything Django is doing.  It's the same 
fundamental principal for why you may turn off webserver logging to 
increase performance, writing to disk is expensive and so when dealing with 
high throughout you probably want to question why.

I've just run that on my laptop and hit your 1000 requests fine. I actually 
them bumped it up to run 6 requests per iteration and still was fine 
writing to disk. I started to have network resource issues when I bumped it 
up further but that was more limitations within chrome

In the real world if you were writing logs like this for information or 
debugging you would be best served to defer them by writing to a message 
queue of sort some, probably FIFO based as its logging, and then have as 
many subscribers as you want dealing with reading and processing those 
queued messages. This could be as few as one so that you never hit a 
deadlock or it could be a few, again it depends on the performance of the 
underlying hardware, what you are writing and where (database, disk, 
memory).


On Wednesday, 22 April 2020 18:23:31 UTC+1, Brian Tiemann wrote:
>
> Hi all,
>
> I was directed here after getting corroboration on #django and elsewhere.
>
> I have what appears to be a bug in which a Django app can deadlock if you 
> hit it with a lot (>3) of AJAX requests within a short time (i.e. all 
> triggered in parallel from a single HTML page). I have a reproducible case 
> here:
>
> https://github.com/data-graham/wedge
>
> I'd really appreciate it if someone could take a look and let me know 
> whether I'm doing something wrong, or if there's something systemic going 
> on. Thanks much!
>
>

-- 
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/1445d05d-eefc-43b1-8913-79d6e55de216%40googlegroups.com.

Re: Deadlock bug in logging? Reproducible case

[Dave Vernon]

Sorry - that message was sent as a 'reply' in error - my colleague uses
ajax with Django a lot and I was trying to forward this to him.

Kind Regards,

Dave


On Wed, 22 Apr 2020 at 18:23, Brian Tiemann  wrote:

> Hi all,
>
> I was directed here after getting corroboration on #django and elsewhere.
>
> I have what appears to be a bug in which a Django app can deadlock if you
> hit it with a lot (>3) of AJAX requests within a short time (i.e. all
> triggered in parallel from a single HTML page). I have a reproducible case
> here:
>
> https://github.com/data-graham/wedge
>
> I'd really appreciate it if someone could take a look and let me know
> whether I'm doing something wrong, or if there's something systemic going
> on. Thanks much!
>
> --
> 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/7fa1a28d-8f54-48cd-9c34-5d1c111ef136%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/CADqmmRxkUyAs3EH%3DggehJTkXb5YM0ENR5wJe19EEHPO8uTF2NQ%40mail.gmail.com.

Re: Deadlock bug in logging? Reproducible case

[Dave Vernon]

FYI 

Sent from my iPhone

> On 22 Apr 2020, at 18:23, Brian Tiemann  wrote:
> 
> 
> Hi all,
> 
> I was directed here after getting corroboration on #django and elsewhere.
> 
> I have what appears to be a bug in which a Django app can deadlock if you hit 
> it with a lot (>3) of AJAX requests within a short time (i.e. all triggered 
> in parallel from a single HTML page). I have a reproducible case here:
> 
> https://github.com/data-graham/wedge
> 
> I'd really appreciate it if someone could take a look and let me know whether 
> I'm doing something wrong, or if there's something systemic going on. Thanks 
> much!
> 
> -- 
> 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/7fa1a28d-8f54-48cd-9c34-5d1c111ef136%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/6BEF80E7-AC03-46A3-91B0-686146F7C17F%40springbourne-tech.com.

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

[Javier Buzzi]

Sounds great Andrew, i'm going to say this up front:

1. You're awesome, thank you for making south and migrations.
2. I'm inevitably need your help on this one, there were a lot of hacks I 
did because I couldn't come up with a better way. I'll get started, as a v1 
to just port all the work done from the other project, and from there I 
will REALLY welcome your insight, guidance, and specially your criticism.

Thank you!
Javier Buzzi

-- 
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/220584c4-a0bc-4535-906e-f120b7080add%40googlegroups.com.

Deadlock bug in logging? Reproducible case

[Brian Tiemann]

Hi all,

I was directed here after getting corroboration on #django and elsewhere.

I have what appears to be a bug in which a Django app can deadlock if you 
hit it with a lot (>3) of AJAX requests within a short time (i.e. all 
triggered in parallel from a single HTML page). I have a reproducible case 
here:

https://github.com/data-graham/wedge

I'd really appreciate it if someone could take a look and let me know 
whether I'm doing something wrong, or if there's something systemic going 
on. Thanks much!

-- 
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/7fa1a28d-8f54-48cd-9c34-5d1c111ef136%40googlegroups.com.

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

[Andrew Godwin]

I definitely think this is worth pursuing - the reason I didn't do it back
in the day was that squashing the entire project involved solving some
rather nasty dependency graph issues if there were any cycles of apps
depending on models from other apps.

If we can overcome that, though, and squash down to just a couple of
migrations each app, it would be nice to have that be a shortcut.

Andrew

On Wed, Apr 22, 2020 at 10:35 AM Javier Buzzi 
wrote:

> This comes from a place of headaches: we're a large team, and our sprint
> are a month long, in that month we generate a lot of migrations, after a
> couple of sprints we see our tests take a real toll when running
> migrations, this is due to constantly adding columns/deleting columns,
> moving data around -- what normally happens with an ever changing app.
>
> The way quashing migrations currently works is by an app by app, I'm
> proposing that if no arguments are supplied (no app_label,
> start_migration_name, migration_name) to squash the entire project, who's
> apps belong to the project of course.
>
> I'm hopping that I can get all the modifications already done to this
> project: https://github.com/kingbuzzman/django-squash and simply
> integrate it directly into the django source. I don't want to take such an
> undertaking and just have the PR be rejected.
>
> Is there any interest for this?
>
> Thanks,
> Javier Buzzi
>
> --
> 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/ad3e7507-01af-49a6-ab15-e1b6d7d32bb7%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/CAFwN1uoC9_QJKpR9-49EABHKukDHgu8FvP3m_k6YVkijcmc2iQ%40mail.gmail.com.

[FEATURE] Allow squashmigrations to squash the whole project

[Javier Buzzi]

This comes from a place of headaches: we're a large team, and our sprint 
are a month long, in that month we generate a lot of migrations, after a 
couple of sprints we see our tests take a real toll when running 
migrations, this is due to constantly adding columns/deleting columns, 
moving data around -- what normally happens with an ever changing app.

The way quashing migrations currently works is by an app by app, I'm 
proposing that if no arguments are supplied (no app_label, 
start_migration_name, migration_name) to squash the entire project, who's 
apps belong to the project of course.

I'm hopping that I can get all the modifications already done to this 
project: https://github.com/kingbuzzman/django-squash and simply integrate 
it directly into the django source. I don't want to take such an 
undertaking and just have the PR be rejected.

Is there any interest for this?

Thanks,
Javier Buzzi

-- 
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/ad3e7507-01af-49a6-ab15-e1b6d7d32bb7%40googlegroups.com.

Re: Remove automatic date-naming of migrations (00XX_auto_YYYMMDD)

[Andrew Godwin]

I am a little mixed on this change - the behaviour during the initial
development was indeed to concatenate names like this, albeit only for
adding fields or models; I thought it looked unwieldy, which is why I added
the "auto" name.

That said, the number is the only part that actually matters, and while the
date is sometimes useful for people to resolve merge conflicts, I don't
think it's better than more informative autogenerated names, so I'm happy
to go with the change.

(60 is a bit long though, maybe we can bump it down to something a bit
shorter?)

Andrew

On Wed, Apr 22, 2020 at 7:06 AM Adam Johnson  wrote:

> Hi djangonauts,
>
> In a blog post earlier this year I outlined my technique to prevent Django
> creating migration files with automatic date names. I had a lot of response
> with other techniques and ended up adding two more techniques to the post.
> It's at
> https://adamj.eu/tech/2020/02/24/how-to-disallow-auto-named-django-migrations/
> .
>
> The problem with such migration names:
>
> When you run Django’s manage.py makemigrations, it will try to generate a
>> name for the migration based upon its contents. For example, if you are
>> adding a single field, it will call the migration 0002_mymodel_myfield.py.
>> However when your migration contains more than one step, it instead uses a
>> simple ‘auto’ name with the current date + time, e.g.
>> 0002_auto_20200113_1837.py. You can provide the -n/--name argument to
>> makemigrations, but developers often forget this.
>>
>> Naming things is a known hard problem in programming. Having migrations
>> with these automatic names makes managing them harder: You can’t tell which
>> is which without opening them, and you could still mix them up if they have
>> similar names due to being generated on the same day.
>>
> Django *currently* sets the migration name to something other than the
> automatic date name in two cases:
>
>- If the migration contains a single operation, it uses a name based
>on that operation, e.g. 00023_remove_model_field, or 0024_add_model_field
>(but not for all operation types)
>- If the migration consists *only* of model creation operations, it
>combines their operation names names, which come as just the lower-cased
>model names e.g. 0025_book_author_sale
>
> I opened a PR to expand the operation naming for the single case to cover
> all built-in operations: https://github.com/django/django/pull/12131
>
> I'd like to propose using this new full coverage of operation naming to
> remove the "auto_MMDD" behaviour, and instead always combine
> operations' "suggested migration names" up until a limit of say 60
> characters. I made a commit for that here:
> https://github.com/adamchainz/django/commit/c2bc6893a05c2c8099e1fb68e688618446641ed6
>
> This would lead to migration names such as:
>
>- 0026_remove_book_title_add_book_description
>
> Whilst perhaps long, they're explict and imo easier to work with than the
> auto_MMDD behaviour.
>
> Mariusz wrote on the PR:
>
> Personally, I'm against removing auto named migrations. IMO chaining
>> operation names is even more confusing.
>>
> --
> 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/CAMyDDM10ACO6wEMZXukN6_xy766Bxa8PQOc7teFEQhRmzWxqwA%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/CAFwN1urecp9nGUqwrsxYox%2BtWzv5FcBBWbANg7E9PGAtUG4m_A%40mail.gmail.com.

Re: Management of static assets

[Carlton Gibson]

Hi David. 

Wowser. Good work! 

(A cup of tea indeed — I should have replied to the first question better 
)

(Inter alia) You raised five questions. These were the last three: 

- Should there be better support for front end JS frameworks
- Should we have support for webpack
- We should support NPM

I think the *key point here is not to bind to a particular package*, 
webpack say. It's already Parcel.js no? — and it'll be something else next 
week. 

django-compressor, beyond concatenating and compressing files has this neat 
ability to define `COMPRESS_PRECOMPILERS` 


Here you can map files to any CLI tool (or write a bit of Python if it gets 
too clever — but TBH I never have to do that). 

An example from a project: 

COMPRESS_PRECOMPILERS = (
("text/x-tailwind", TAILWIND_COMMAND), # Compile tailwind via 
PostCSS, with tree-shaking, FTW 
# ("text/x-scss", SASS_COMMAND),  # Would compile Sass. 
Oops didn't delete it yet. 
("text/x-elm", ELM_MAKE_COMMAND),# Run elm make.
)

You can just as easily put in webpack or parcel or babel (or a chain of any 
or all of them...) 

It's that plus the offline compress tool that means I've been happy with 
compressor for a long time — I just never had to move on. 
(There's a point where you hand off to a frontend specialist but ...) 

So, particularly given how fast the tools landscape moves here, and how 
slow Django moves in comparison, some kind of wrapper where you shell out 
to A.N.Tool — it doesn't have to be JavaScript. It might be make, or 
pyinvoke — rather than something tied to webpack, as the example, would be 
a requirement for me. 


*Not sure* how much of this we need to pull into Django itself? compressor, 
say, does the whole combine and compress thing well. If we pull that in are 
we going to do the same for image optimization? Or pull in Whitenoise? 
Or...? For a user just with contib.staticfiles, what's the very next thing 
we could do that would make life easier? (i.e. is "I can't run webpack" top 
of their list?) — What can we do better in core vs a third-party app? — Is 
that just awareness, which is not a nothing? 
Note the "not sure" — I think about this a lot, it's a big issue, but I 
don't have a single answer: I've got what I do, and that works for me, but 
I see lots of people doing different with success. 

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/4cda64f0-2630-4377-a2d7-a2312a006ae9%40googlegroups.com.

Re: Remove automatic date-naming of migrations (00XX_auto_YYYMMDD)

[Jon Dufresne]

> I'd like to propose using this new full coverage of operation naming to
remove the "auto_MMDD" behaviour

+1 on this proposal. As you've noted in your blog post, I find the default
auto name extremely opaque. Projects I work on normally have an internal
policy to change these names to something more informative. Inevitably,
this means there is always a bit of a learning process for new team
members. If Django handled this more automatically, it would remove some of
this learning process.

> and instead always combine operations' "suggested migration names"

This sounds reasonable to me. If there is concern about words blending into
one another, we could separate them by a double underscore:
0026_remove_book_title__add_book_description. I would personally be fine
with either.

> up until a limit of say 60 characters

Did you have a suggestion for this situation? Revert back to auto-naming or
request the user to name the migration?

On Wed, Apr 22, 2020 at 6:06 AM Adam Johnson  wrote:

> Hi djangonauts,
>
> In a blog post earlier this year I outlined my technique to prevent Django
> creating migration files with automatic date names. I had a lot of response
> with other techniques and ended up adding two more techniques to the post.
> It's at
> https://adamj.eu/tech/2020/02/24/how-to-disallow-auto-named-django-migrations/
> .
>
> The problem with such migration names:
>
> When you run Django’s manage.py makemigrations, it will try to generate a
>> name for the migration based upon its contents. For example, if you are
>> adding a single field, it will call the migration 0002_mymodel_myfield.py.
>> However when your migration contains more than one step, it instead uses a
>> simple ‘auto’ name with the current date + time, e.g.
>> 0002_auto_20200113_1837.py. You can provide the -n/--name argument to
>> makemigrations, but developers often forget this.
>>
>> Naming things is a known hard problem in programming. Having migrations
>> with these automatic names makes managing them harder: You can’t tell which
>> is which without opening them, and you could still mix them up if they have
>> similar names due to being generated on the same day.
>>
> Django *currently* sets the migration name to something other than the
> automatic date name in two cases:
>
>- If the migration contains a single operation, it uses a name based
>on that operation, e.g. 00023_remove_model_field, or 0024_add_model_field
>(but not for all operation types)
>- If the migration consists *only* of model creation operations, it
>combines their operation names names, which come as just the lower-cased
>model names e.g. 0025_book_author_sale
>
> I opened a PR to expand the operation naming for the single case to cover
> all built-in operations: https://github.com/django/django/pull/12131
>
> I'd like to propose using this new full coverage of operation naming to
> remove the "auto_MMDD" behaviour, and instead always combine
> operations' "suggested migration names" up until a limit of say 60
> characters. I made a commit for that here:
> https://github.com/adamchainz/django/commit/c2bc6893a05c2c8099e1fb68e688618446641ed6
>
> This would lead to migration names such as:
>
>- 0026_remove_book_title_add_book_description
>
> Whilst perhaps long, they're explict and imo easier to work with than the
> auto_MMDD behaviour.
>
> Mariusz wrote on the PR:
>
> Personally, I'm against removing auto named migrations. IMO chaining
>> operation names is even more confusing.
>>
> --
> 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/CAMyDDM10ACO6wEMZXukN6_xy766Bxa8PQOc7teFEQhRmzWxqwA%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/CADhq2b4-LHwmKpMTwO2%2BFwLSUCKYwPzwQs28fbH5edPdqjNGRw%40mail.gmail.com.

Re: Providing inline "force_login" if "user" keyword argument provided to TestClient. calls (or TestClient.generic)

[Adam Johnson]

Hi Pavel

I think this is a reasonable suggestion to allow tests to be written
quickly. It should be noted django-webtest
 supports this argument
already.

I'm not sure it's as simple as a force_login before the request though.

Take these tests:

self.client.force_login(normal_user)
response1 = self.client.get('/home/')
# assert book not visible to "normal user" even though it would be visible
to admins
self.client.post('/make-book-visible/1/', user=admin_user)
response2 = self.client.get('/home/')
# assert book now visible to "normal user"

I'd argue it's a reasonable reading that the second get() of /home/ should
use normal_user, rather than be left as admin_user after the post().

I think perhaps making `force_login` a context manager, that reverts login
state (and cookies) on __exit__, and using that inside the Client's
request-making method could work. Not sure how feasible that is though.

Thanks,

Adam

On Wed, 22 Apr 2020 at 11:48, Pavel Savchenko  wrote:

> Hi all,
>
> As a long time Django user, I often found the requirement to use login or
> force_login somewhat cumbersome.
>
> In comparison, pylons' WebTest has a user keyword argument e.g in their
> get method, which does that authentication inline.
>
> I am suggesting we make a call to login or force_login if a related
> argument is passed. Something akin to this:
>
> diff --git a/django/test/client.py b/django/test/client.py
> index c460832461..b0a3f89c60 100644
> --- a/django/test/client.py
> +++ b/django/test/client.py
> @@ -726,8 +726,10 @@ class Client(ClientMixin, RequestFactory):
>  self.cookies.update(response.cookies)
>  return response
>
> -def get(self, path, data=None, follow=False, secure=False, **extra):
> +def get(self, path, data=None, follow=False, secure=False, user=None,
> **extra):
>  """Request a response from the server using GET."""
> +if user:
> +self.force_login(user)
>  self.extra = extra
>  response = super().get(path, data=data, secure=secure, **extra)
>  if follow:
>
> I would love to discuss this suggestion with the rest of you, hopeful to
> get some more ideas or an agreement or sorts.
>
> And later, if this is agreed to be useful to the community, I could work
> on the PR.
>
> Kind Regards,
> Pavel
>
> --
> 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/d5185a29-4ded-4966-87b3-1149c970eec5%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/CAMyDDM1wd-kNQnJiC4VFkdi6jk%3D82%2BuFv8GiSn-wQAtmYg4ozw%40mail.gmail.com.

Re: Remove automatic date-naming of migrations (00XX_auto_YYYMMDD)

[Asif Saif Uddin]

I Like the idea of Claude.
Asif

On Wednesday, April 22, 2020 at 7:23:22 PM UTC+6, Claude Paroz wrote:
>
> Le mercredi 22 avril 2020 15:06:12 UTC+2, Adam Johnson a écrit :
>>
>> I'd like to propose using this new full coverage of operation naming to 
>> remove the "auto_MMDD" behaviour, and instead always combine 
>> operations' "suggested migration names" up until a limit of say 60 
>> characters. I made a commit for that here: 
>> https://github.com/adamchainz/django/commit/c2bc6893a05c2c8099e1fb68e688618446641ed6
>> ...
>> Mariusz wrote on the PR:
>>
>> Personally, I'm against removing auto named migrations. IMO chaining 
>>> operation names is even more confusing.  
>>>
>>
> An alternative could be to ask the user in interactive mode (and keep the 
> current behaviour in non-interactive mode).
>
> 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/0bf74280-1620-4954-9629-3fd52d9a8b1e%40googlegroups.com.

Re: Uwsgi not sending parallel all(except one) tasks to celery

[Abhijeet Viswa]

Hi!

I think you've found the wrong mailing list for this post. This mailing
list is for discussing the development of Django itself, not for support
using Django. This means the discussions of bugs and features in Django
itself, rather than in your code using it. People on this list are unlikely
to answer your support query with their limited time and energy.

For support, please follow the "Getting Help" page:
https://docs.djangoproject.com/en/3.0/faq/help/. This will help you find
people who are willing to support you, and to ask your question in a way
that makes it easy for them to answer.

Thanks for your understanding and all the best.

On Wed, 22 Apr, 2020, 18:51 sandeep,  wrote:

> Hi, Im facing issue like I'm trying to send 30 parallel tasks to the
> celery and trying to get back the result using apply_async() but uwsgi is
> sending only one task to celery and
> not giving back the result to python code. Thing is it is working fine
> with flask development server but when i uwsgi and nginx I'm getting stuck.
> Please suggest solution.
>
> After 60 seconds it is getting time out as nginx timeout is 60s.
>
> --
> 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/b9e0f23c-f6b1-4613-aa7e-2454f5cd592f%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/CAP1-YrrTK3Grybys7PiB9ojjEBAd8t7SuEUWkFUm8S41cNb6vw%40mail.gmail.com.

Re: While executing a Celery Task , Error Occured: 'AsyncResult' object is not iterable

[Adam Johnson]

Hi!

I think you've found the wrong mailing list for this post. This mailing
list is for discussing the development of Django itself, not for support
using Django. This means the discussions of bugs and features in Django
itself, rather than in your code using it. People on this list are unlikely
to answer your support query with their limited time and energy.

For support, please follow the "Getting Help" page:
https://docs.djangoproject.com/en/3.0/faq/help/ . This will help you find
people who are willing to support you, and to ask your question in a way
that makes it easy for them to answer.

Thanks for your understanding and all the best,

Adam

On Wed, 22 Apr 2020 at 04:42, Dilipkumar Noone  wrote:

> I am Using Celery to perform a task in the background on form submission.
> As soon as form is submitted during POST request, I have created a task to
> execute in the back ground using delay method. This task processes some
> click operations on some other web using selenium web driver and return two
> python lists after task execution. Based on list content I want to display
> pop up message.
>
> When I execute the task using celery and run the Django web development
> server on form submit , I am getting error message: 'AsyncResult' object is
> not iterable”.
>
> Please suggest how to resolve this issue and proceed further.
>
> Here is my code snippet: sample List content which obtained through
> selenium operations on web page is as shown below:
>
>
> board_not_used_list = ['16123','14960']
> board_mgr_permissions_not_present_list = [ '23456','45678']
>
>
> views.py:
> 
> def conclude_key_issue_form(request, id=None):
> if id:
> action = 'edit'
> model = get_object_or_404(ConcludeKeyIssues, pk=id)
>
> else:
> action = 'submit'
> model = ConcludeKeyIssues()
>
> message = ""
>
>
> if request.method == 'POST':
>
> form = ConcludeKeyIssuesForm(request.POST, instance=model)
>
> selected_model_name = request.POST.get('registered_model')
>
>
> if form.is_valid():
>
> new_key_issue_request = form.save(commit=False)
> new_key_issue_request.integrator_id = request.user.username
>
> integrator_username = new_key_issue_request.integrator_id
> integrator_password = form.cleaned_data['integrator_pwd']
>
> new_key_issue_request.integrator_pwd = integrator_password
>
> new_key_issue_request.save()
> form.save_m2m()
>
> created_pk = new_key_issue_request.pk
>
> if id is None:
> board_not_used_list,
>board_mgr_permissions_not_present_list=
>   task_check_board_availability_and_permissions.delay(created_pk)
>
> if board_not_used_list and
> board_mgr_permissions_not_present_list:
> alert_flag = True
> alert_message = "SAS Board ID's:{} in Not Used state."
> context = {'form': form, 'registered_model_data': 
> registered_models,
>'alert': alert_flag, 'alert_message': 
> json.dumps(alert_message)}
> return render(request, 'ConcludeKeyIssue.html', context)
>
> elif not board_not_used_list and 
> board_mgr_permissions_not_present_list:
> alert_flag = True
> alert_message = "You don't have Board Manager Permissions"
> context = {'form': form, 'registered_model_data': 
> registered_models,
>'alert': alert_flag, 'alert_message': 
> json.dumps(alert_message)}
> return render(request, 'ConcludeKeyIssue.html', context)
>
> return HttpResponseRedirect('/swatapp/ConcludeKeyIssueList')
> else:
> print("Fill Conclude Key Issues")
> form = ConcludeKeyIssuesForm(instance=model)
>
> context = {'form': form,'Message': message, 'action': action}
>
> return render(request, 'ConcludeKeyIssue.html', context)
> Tasks.py:@app.task(name="task_check_board_availability_and_permissions")def
>  task_check_board_availability_and_permissions(created_pk):
> print("From tasks.py conclude_key_issue_through_selenium")
>
> print("Conclude Key Issue Through Selenium")
>
> latest_record_pk = created_pk
>
> # Get the instances of ConcludeKeyIssues
> conclude_key_issue_obj_list = ConcludeKeyIssues.objects.all()
>
> # Get the latest created record details
> get_created_record_details = 
> ConcludeKeyIssues.objects.get(pk=latest_record_pk)
>
> # Get the id or location value of selected from SAS URL
> sas_board_ids = get_created_record_details.sas_ids
>
> # Get SAS Board IDs in list
> sas_board_ids_list = sas_board_ids.split(",")
>
>
> # Input username and password
> username = get_created_record_details.integrator_id
> password = 

Re: Generate JWTs with Django

[Adam Johnson]

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.

Re: Remove automatic date-naming of migrations (00XX_auto_YYYMMDD)

[Claude Paroz]

Le mercredi 22 avril 2020 15:06:12 UTC+2, Adam Johnson a écrit :
>
> I'd like to propose using this new full coverage of operation naming to 
> remove the "auto_MMDD" behaviour, and instead always combine 
> operations' "suggested migration names" up until a limit of say 60 
> characters. I made a commit for that here: 
> https://github.com/adamchainz/django/commit/c2bc6893a05c2c8099e1fb68e688618446641ed6
> ...
> Mariusz wrote on the PR:
>
> Personally, I'm against removing auto named migrations. IMO chaining 
>> operation names is even more confusing.  
>>
>
An alternative could be to ask the user in interactive mode (and keep the 
current behaviour in non-interactive mode).

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/515d4b08-e17f-4267-800f-966146ff0886%40googlegroups.com.

Uwsgi not sending parallel all(except one) tasks to celery

[sandeep]

Hi, Im facing issue like I'm trying to send 30 parallel tasks to the celery 
and trying to get back the result using apply_async() but uwsgi is sending 
only one task to celery and
not giving back the result to python code. Thing is it is working fine with 
flask development server but when i uwsgi and nginx I'm getting stuck. 
Please suggest solution.

After 60 seconds it is getting time out as nginx timeout is 60s.

-- 
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/b9e0f23c-f6b1-4613-aa7e-2454f5cd592f%40googlegroups.com.

While executing a Celery Task , Error Occured: 'AsyncResult' object is not iterable

[Dilipkumar Noone]

I am Using Celery to perform a task in the background on form submission. 
As soon as form is submitted during POST request, I have created a task to 
execute in the back ground using delay method. This task processes some 
click operations on some other web using selenium web driver and return two 
python lists after task execution. Based on list content I want to display 
pop up message.

When I execute the task using celery and run the Django web development 
server on form submit , I am getting error message: 'AsyncResult' object is 
not iterable”.

Please suggest how to resolve this issue and proceed further.

Here is my code snippet: sample List content which obtained through 
selenium operations on web page is as shown below:


board_not_used_list = ['16123','14960']
board_mgr_permissions_not_present_list = [ '23456','45678']


views.py:
 
def conclude_key_issue_form(request, id=None):
if id:
action = 'edit'
model = get_object_or_404(ConcludeKeyIssues, pk=id)

else:
action = 'submit'
model = ConcludeKeyIssues()

message = ""   


if request.method == 'POST':

form = ConcludeKeyIssuesForm(request.POST, instance=model)

selected_model_name = request.POST.get('registered_model')  


if form.is_valid():

new_key_issue_request = form.save(commit=False)
new_key_issue_request.integrator_id = request.user.username

integrator_username = new_key_issue_request.integrator_id
integrator_password = form.cleaned_data['integrator_pwd']

new_key_issue_request.integrator_pwd = integrator_password

new_key_issue_request.save()
form.save_m2m()

created_pk = new_key_issue_request.pk

if id is None:
board_not_used_list,
   board_mgr_permissions_not_present_list=  
   
  task_check_board_availability_and_permissions.delay(created_pk)

if board_not_used_list and 
board_mgr_permissions_not_present_list:
alert_flag = True
alert_message = "SAS Board ID's:{} in Not Used state."
context = {'form': form, 'registered_model_data': 
registered_models,   
   'alert': alert_flag, 'alert_message': 
json.dumps(alert_message)}
return render(request, 'ConcludeKeyIssue.html', context)

elif not board_not_used_list and 
board_mgr_permissions_not_present_list:
alert_flag = True
alert_message = "You don't have Board Manager Permissions"
context = {'form': form, 'registered_model_data': 
registered_models,
   'alert': alert_flag, 'alert_message': 
json.dumps(alert_message)}
return render(request, 'ConcludeKeyIssue.html', context)

return HttpResponseRedirect('/swatapp/ConcludeKeyIssueList')
else:
print("Fill Conclude Key Issues")
form = ConcludeKeyIssuesForm(instance=model)

context = {'form': form,'Message': message, 'action': action}

return render(request, 'ConcludeKeyIssue.html', context)
Tasks.py:@app.task(name="task_check_board_availability_and_permissions")def
 task_check_board_availability_and_permissions(created_pk):
print("From tasks.py conclude_key_issue_through_selenium")

print("Conclude Key Issue Through Selenium")

latest_record_pk = created_pk

# Get the instances of ConcludeKeyIssues
conclude_key_issue_obj_list = ConcludeKeyIssues.objects.all()

# Get the latest created record details
get_created_record_details = 
ConcludeKeyIssues.objects.get(pk=latest_record_pk)

# Get the id or location value of selected from SAS URL
sas_board_ids = get_created_record_details.sas_ids

# Get SAS Board IDs in list
sas_board_ids_list = sas_board_ids.split(",")


# Input username and password
username = get_created_record_details.integrator_id
password = get_created_record_details.integrator_pwd

board_not_used_list, board_mgr_permissions_not_present_list = \

check_board_availability_and_permissions_for_all_requested_sas(sas_board_ids_list,
 username, 
   password)


return board_not_used_list, board_mgr_permissions_not_present_list



settings.py:
INSTALLED_APPS = [
'django.contrib.admin',
'django.contrib.auth',
'django.contrib.contenttypes',
'django.contrib.sessions',
'django.contrib.messages',
'django.contrib.staticfiles',
'crispy_forms',
'swatapp',
'django_celery_results',]
CELERY_BROKER_URL = 'amqp://guest:guest@localhost:5672//'
CELERY_RESULT_BACKEND = 'django-db'


1.Please suggest how to resolve this error and proceed further.

2.How to retrieve the 2 lists 

Re: Remove automatic date-naming of migrations (00XX_auto_YYYMMDD)

[Caio Ariede]

I think making it possible to customize how migration names are generated has a 
great value. Changing something from “auto” to some better/descriptive name has 
its value, but I can also see people creating their own strategies for naming 
migrations.

I work on a project where migration names are fixed to “auto”. We use a similar 
technique to those mentioned in the blog post to do that. The reason is that we 
want to force developers to get conflicts (git) on migration names during the 
review process, rather than having to handle migration merging manually during 
deploy

--
Caio



> On Apr 22, 2020, at 10:05, Adam Johnson  wrote:
> 
> Hi djangonauts,
> 
> In a blog post earlier this year I outlined my technique to prevent Django 
> creating migration files with automatic date names. I had a lot of response 
> with other techniques and ended up adding two more techniques to the post. 
> It's at 
> https://adamj.eu/tech/2020/02/24/how-to-disallow-auto-named-django-migrations/
>  
> 
>  .
> 
> The problem with such migration names:
> 
> When you run Django’s manage.py makemigrations, it will try to generate a 
> name for the migration based upon its contents. For example, if you are 
> adding a single field, it will call the migration 0002_mymodel_myfield.py. 
> However when your migration contains more than one step, it instead uses a 
> simple ‘auto’ name with the current date + time, e.g. 
> 0002_auto_20200113_1837.py. You can provide the -n/--name argument to 
> makemigrations, but developers often forget this.
> 
> Naming things is a known hard problem in programming. Having migrations with 
> these automatic names makes managing them harder: You can’t tell which is 
> which without opening them, and you could still mix them up if they have 
> similar names due to being generated on the same day.
> 
> Django *currently* sets the migration name to something other than the 
> automatic date name in two cases:
> If the migration contains a single operation, it uses a name based on that 
> operation, e.g. 00023_remove_model_field, or 0024_add_model_field (but not 
> for all operation types)
> If the migration consists *only* of model creation operations, it combines 
> their operation names names, which come as just the lower-cased model names 
> e.g. 0025_book_author_sale
> I opened a PR to expand the operation naming for the single case to cover all 
> built-in operations: https://github.com/django/django/pull/12131 
>   
> 
> I'd like to propose using this new full coverage of operation naming to 
> remove the "auto_MMDD" behaviour, and instead always combine operations' 
> "suggested migration names" up until a limit of say 60 characters. I made a 
> commit for that here: 
> https://github.com/adamchainz/django/commit/c2bc6893a05c2c8099e1fb68e688618446641ed6
>  
> 
> 
> This would lead to migration names such as:
> 0026_remove_book_title_add_book_description
> Whilst perhaps long, they're explict and imo easier to work with than the 
> auto_MMDD behaviour.
> 
> Mariusz wrote on the PR:
> 
> Personally, I'm against removing auto named migrations. IMO chaining 
> operation names is even more confusing. 
> -- 
> 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/CAMyDDM10ACO6wEMZXukN6_xy766Bxa8PQOc7teFEQhRmzWxqwA%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/EFFA0FA4-2346-422D-BBCF-9B836F1AB421%40gmail.com.

Remove automatic date-naming of migrations (00XX_auto_YYYMMDD)

[Adam Johnson]

Hi djangonauts,

In a blog post earlier this year I outlined my technique to prevent Django
creating migration files with automatic date names. I had a lot of response
with other techniques and ended up adding two more techniques to the post.
It's at
https://adamj.eu/tech/2020/02/24/how-to-disallow-auto-named-django-migrations/
.

The problem with such migration names:

When you run Django’s manage.py makemigrations, it will try to generate a
> name for the migration based upon its contents. For example, if you are
> adding a single field, it will call the migration 0002_mymodel_myfield.py.
> However when your migration contains more than one step, it instead uses a
> simple ‘auto’ name with the current date + time, e.g.
> 0002_auto_20200113_1837.py. You can provide the -n/--name argument to
> makemigrations, but developers often forget this.
>
> Naming things is a known hard problem in programming. Having migrations
> with these automatic names makes managing them harder: You can’t tell which
> is which without opening them, and you could still mix them up if they have
> similar names due to being generated on the same day.
>
Django *currently* sets the migration name to something other than the
automatic date name in two cases:

   - If the migration contains a single operation, it uses a name based on
   that operation, e.g. 00023_remove_model_field, or 0024_add_model_field (but
   not for all operation types)
   - If the migration consists *only* of model creation operations, it
   combines their operation names names, which come as just the lower-cased
   model names e.g. 0025_book_author_sale

I opened a PR to expand the operation naming for the single case to cover
all built-in operations: https://github.com/django/django/pull/12131

I'd like to propose using this new full coverage of operation naming to
remove the "auto_MMDD" behaviour, and instead always combine
operations' "suggested migration names" up until a limit of say 60
characters. I made a commit for that here:
https://github.com/adamchainz/django/commit/c2bc6893a05c2c8099e1fb68e688618446641ed6

This would lead to migration names such as:

   - 0026_remove_book_title_add_book_description

Whilst perhaps long, they're explict and imo easier to work with than the
auto_MMDD behaviour.

Mariusz wrote on the PR:

Personally, I'm against removing auto named migrations. IMO chaining
> operation names is even more confusing.
>
-- 
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/CAMyDDM10ACO6wEMZXukN6_xy766Bxa8PQOc7teFEQhRmzWxqwA%40mail.gmail.com.

Providing inline "force_login" if "user" keyword argument provided to TestClient. calls (or TestClient.generic)

[Pavel Savchenko]

Hi all,

As a long time Django user, I often found the requirement to use login or 
force_login somewhat cumbersome.

In comparison, pylons' WebTest has a user keyword argument e.g in their get 
method, 
which does that authentication inline.

I am suggesting we make a call to login or force_login if a related 
argument is passed. Something akin to this:

diff --git a/django/test/client.py b/django/test/client.py
index c460832461..b0a3f89c60 100644
--- a/django/test/client.py
+++ b/django/test/client.py
@@ -726,8 +726,10 @@ class Client(ClientMixin, RequestFactory):
 self.cookies.update(response.cookies)
 return response
 
-def get(self, path, data=None, follow=False, secure=False, **extra):
+def get(self, path, data=None, follow=False, secure=False, user=None, 
**extra):
 """Request a response from the server using GET."""
+if user:
+self.force_login(user)
 self.extra = extra
 response = super().get(path, data=data, secure=secure, **extra)
 if follow:

I would love to discuss this suggestion with the rest of you, hopeful to 
get some more ideas or an agreement or sorts.

And later, if this is agreed to be useful to the community, I could work on 
the PR.

Kind Regards,
Pavel

-- 
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/d5185a29-4ded-4966-87b3-1149c970eec5%40googlegroups.com.

Re: Generate JWTs with Django

[Claude Paroz]

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.