Google season of docs

[Mhd Ali]

Will Django be participating in Google season of docs this year?

-- 
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/CANV73fEEMg_yDm6S_a_jihJZFE2H7ArgpHPY%2BqCVDg2oVgHQpw%40mail.gmail.com.

Re: Match i18n.set_language view next param / Referer header against ALLOWED_HOSTS

['Adam Johnson' via Django developers (Contributions to Django itself)]

>
> For exemple, if a user changes language at subdomain.exemple.com/whatever,
> by sending a POST request to exemple.com/i18n/setlang, it will be
> redirected to exemple.com/.


Why would you not use subdomain.example.com/i18n/setlang to change the
user's language? That seems like it would work.

In my experience multi-domain setups are very diverse. Every site seems to
divide functionality and auth between domains differently.

I'm not sure Django should support your suggested way of splitting up
domains out of the box. Ultimately the set_language view is "set a cookie
and redirect" and I don't think that's much functionality to reimplement
yourself, as a cost for choosing a particular pattern of splitting up
functionality between subdomains.

(P.S. in future please use "example.com" in examples - it seems "exemple.com"
is registered for commercial purposes)

On Sat, 3 Apr 2021 at 23:05, LeMinaw  wrote:

> Hello,
>
> I'd like to get some input about a -rather simple- suggestion concerning
> the set_language view.
>
> According to the docs, for now:
>
> *After setting the language choice, Django looks for a next parameter in
> the POST or GET data. If that is found and Django considers it to be a safe
> URL (i.e. it doesn’t point to a different host and uses a safe scheme), a
> redirect to that URL will be performed. Otherwise, Django may fall back to
> redirecting the user to the URL from the Referer header or, if it is not
> set, to / [...].*
>
> Note: looking at the source
> ,
> the Referer header host is checked in the same way the next POST/GET
> params are (it is not that clear in the docs atm, but that is another story
> :) ).
>
> While this behavior seems reasonable, it is not conveniant at all when
> dealing with multi-tenancy (i.e. when Django serves requests from several
> subdomains).
>
> For exemple, if a user changes language at subdomain.exemple.com/whatever,
> by sending a POST request to exemple.com/i18n/setlang, it will be
> redirected to exemple.com/.
>
> As the title suggets, this could be avoided by matching both the next param
> and the Referer header to the ALLOWED_HOSTS setting instead of
> restricting it to the current host only (taking wildcards, such as .
> exemple.com, into account).
>
> If this looks like a good improvement to you, I can start filling a
> ticket/working on a patch for this.
> Kind regards,
> Renaud
>
> --
> 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/cdc7c839-dd3d-4d21-8d4d-7c377a0e1051n%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/CAMyDDM0QyiumTbcevxriZh09rK8_bptj4U7oDo1XLWJcz%3D6itg%40mail.gmail.com.

Test fails silently when using --tag

[Cammil Taank]

Hi All,

When I run tests using the --tag option, and there is a module level
exception, the tests seem to pass without any errors.

Steps to reproduce:
1. Add this to tests:
from django.test import TestCase
from django.test import tag

assert 0

@tag('abc')
class TempTest(TestCase):

def test_basic(self):
self.assertFalse(True)

2. Run python manage.py test
This should fail as expected

3. Run python manage.py test --tag=abc
This for me passes without any error

Cammil


ontono.com/cammil
taanktech.com
linkedin.com/cammiltaank 

-- 
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/CACc%3DA%3D1gOcps2ameDdo4qkDo64%3DcRB99SrbH%3DxrKx5XeSE%2Bk5Q%40mail.gmail.com.

Re: Match i18n.set_language view next param / Referer header against ALLOWED_HOSTS

[Le minaw]

Thanks for your answer. I'll go point by point through it:

Why would you not use subdomain.example.com/i18n/setlang 
 to change the user's 
language? That seems like it would work.
It would, but then the setlang view has to be routed to all subdomains. 
Why this might not be a big deal if you only have a few subdomains, one 
might argue it violates DRY. Also, that would mean extra work will be 
needed when reversing the setlang pattern (e.g. in templates), as each 
subdomain would have to reverse to its own setlang pattern.


I'm not sure Django should support your suggested way of splitting up 
domains out of the box.


I don't think Django should *support* multi-tenancy functionnality 
either, as almost every part of the framework is 
subdomain/host-agnostic. It is fine to rely on third-party packages for 
this.


In fact, this is basically my point: as the rest of the framework, I 
think the setlang view has to be host-agnostic. While having a safeguard 
on both the Referer and next param might be a good thing, I don't see 
any good reason to enforce this kind of specific behavior.


In my experience multi-domain setups are very diverse. Every site 
seems to divide functionality and auth between domains differently.


Agreed, and in my opinion, this is exactly why this rather strict 
behavior is not a good thing. I think the framework and its components 
should be as unopinionated as they can -reasonnably- be.


Ultimately the set_language view is "set a cookie and redirect" and I 
don't think that's much functionality to reimplement yourself, as a 
cost for choosing a particular pattern of splitting up functionality 
between subdomains.


For sure it is not, and that is exactly what we are doing for now 
(basically, remplementing the view in a separate app only for this). I 
just thought it would be a good improvement of the framework, that would 
save extra work -and I can't think of any drawback of matching against 
ALLOWED_HOSTS instead of restricting to the current host.



Le 04/04/2021 à 13:23, 'Adam Johnson' via Django developers 
(Contributions to Django itself) a écrit :


For exemple, if a user changes language at
subdomain.exemple.com/whatever
, by sending a POST request
to exemple.com/i18n/setlang , it
will be redirected to exemple.com/ . 



Why would you not use subdomain.example.com/i18n/setlang 
 to change the user's 
language? That seems like it would work.


In my experience multi-domain setups are very diverse. Every site 
seems to divide functionality and auth between domains differently.


I'm not sure Django should support your suggested way of splitting up 
domains out of the box. Ultimately the set_language view is "set a 
cookie and redirect" and I don't think that's much functionality to 
reimplement yourself, as a cost for choosing a particular pattern of 
splitting up functionality between subdomains.


(P.S. in future please use "example.com " in 
examples - it seems "exemple.com " is registered 
for commercial purposes)


On Sat, 3 Apr 2021 at 23:05, LeMinaw > wrote:


Hello,

I'd like to get some input about a -rather simple- suggestion
concerning the set_language view.

According to the docs, for now:

/After setting the language choice, Django looks for a next
parameter in the POST or GET data. If that is found and Django
considers it to be a safe URL (i.e. *it doesn’t point to a
different host* and uses a safe scheme), a redirect to that URL
will be performed. Otherwise, Django may fall back to redirecting
the user to the URL from the Referer header or, if it is not set,
to / [...]./

Note: looking at the source

,
the Referer header host is checked in the same way the next
POST/GET params are (it is not that clear in the docs atm, but
that is another story :) ).

While this behavior seems reasonable, it is not conveniant at all
when dealing with multi-tenancy (i.e. when Django serves requests
from several subdomains).

For exemple, if a user changes language at
subdomain.exemple.com/whatever
, by sending a POST request
to exemple.com/i18n/setlang , it
will be redirected to exemple.com/ .

As the title suggets, this could be avoided by matching both the
next param and the Referer header to the ALLOWED_HOSTS setting
instead of restricting it to the current host only (taking
wildcards, such as .exemple.com , into account).

If this looks like a good improvement to you, I can start 

Re: GSOC Proposal: Adding Redis Cache Backend To Django Core.

[Dan Davis]

cache coherence can be a problem, but I am thinking more about what happens
when the cache, which is supposed to make things faster, is not available
due to error.  Django ends up waiting for it.  Each request waits for the
cache, and this is a hard problem because there is no common shared place
to write that the cache is down.  However, introducing anything like that
introduces problems also with cache coherence.

On Fri, Apr 2, 2021 at 3:17 AM Girish Sontakke 
wrote:

> Hello,
> If I am not wrong, you are talking about the cache incoherence
>  problem.  Currently, I
> don't have any concrete idea to tackle this problem but I will try to
> figure it out.
> Thanks for bringing this to concern.
>
> Kind Regards,
> Girish
>
> On Thursday, April 1, 2021 at 8:39:59 PM UTC+5:30 dans...@gmail.com wrote:
>
>> Since REDIS is already usable as a cache for Django using 3rd party code,
>> I would rather see a circuit breaker pattern applied to the cache, across
>> all backends.  I'm not that active in maintaining Django right now, but a
>> cache may not be fully redundant, and it also can fail. If the cache is
>> truly used as a cache, then it should be possible to try the cache, and if
>> it fails for several tries, then Django could start to bypass it, and then
>> try to re-enable it later.
>>
>> This is perhaps a bigger effort than a GSOC project - the hard part is
>> doing this across multiple processes and threads.  What does it mean if the
>> cache is only available for some fraction of the instances/processes
>> hosting a project?
>>
>>
>> On Thu, Apr 1, 2021 at 8:25 AM Girish Sontakke 
>> wrote:
>>
>>> Hello Carlton,
>>> As suggested by you I made some revisions to my proposal. Still, it is
>>> not a perfect one, I am trying to improve it. Thanks a lot for the help.
>>>
>>> Kind Regards,
>>> Girish
>>> On Thursday, April 1, 2021 at 12:15:53 AM UTC+5:30 carlton...@gmail.com
>>> wrote:
>>>


 On 31 Mar 2021, at 11:00, Girish Sontakke  wrote:

 Now I have doubt that whether I should remove *Provides Many
 Data-Structures *point from the "Why Redis" section or keep it there?.


 I don’t think it’s vital either way… but it seems a distraction. That
 Redis has HyperLogLog isn’t something that will matter at all to the cache
 backend.

 I’d try to focus on the details of the implementation: Look at the
 backend API, set(), get() &co. Look at the two existing third-party
 backend, and see what they do there.

 I’d also think about getting the documentation right — there are a few
 options with installs and connections and … — you don’t have to solve all
 of those in the proposal but showing that you’re aware of them would be
 good.

 I hope that helps.

 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-develop...@googlegroups.com.
>>> To view this discussion on the web visit
>>> https://groups.google.com/d/msgid/django-developers/97c757dd-b09f-49f4-9e3f-0ee4a8e4887cn%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/399dbcd7-7127-4715-b2cd-3f5d349d605bn%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/CAFzonYbPq07r%2BTr30n30rC87LN9VOmc_0Fu_5bxubEXvgigb0g%40mail.gmail.com.

Re: GSoC Proposal: (Migrations) Adapt schema editors to operate from model states instead of fake rendered models.

[Manav Agarwal]

I have added the proposed solution in the proposal. 
I request fellow developers to please help me with their respective 
suggestions, thoughts or feedback, so that I may develop a better and 
practical proposal.

Regards,
Manav Agarwal

On Friday, April 2, 2021 at 3:09:46 AM UTC+5:30 Manav Agarwal wrote:

> Hello everyone,
> My name is Manav. I’m a Computer Science and Engineering junior at Dr. 
> A.P.J. Abdul Kalam Technical University in India.
> I started contributing to Django in October 2020 and have solved many issues 
> on trac 
> 
> .
> I read through the GSoC Idea List and the Migration topic stood out for 
> me. I found the idea to adapt schema editors to operate from model states 
> instead of fake rendered models really interesting.
> I am working on this for the last 1 month and I have made myself familiar 
> with the whole migrations framework codebase. I drafted a basic proposal 
>  in 
> which I would be updating the complete solution after some discussion to 
> make the solution more concrete, practical, and effective.
> The problem with the Migration framework is briefly described in the 
> proposal 
>  
> itself. 
> After understanding the problem I came up with a few solutions which are 
> listed below:
>
>1. As Suggested by @MarkusH , 
>A central registry to store all dependencies in django.apps.registry.Apps
>
>Or
>
>2. Designing a new metaclass for ModelState just like we have ModelBase 
>
> 
>  
>for Model. As then we would be able to use Options 
>
> 
>  
>with _meta in ModelState which will help in fetching the field details.
>
> Personally, I found Migration Framework damn interesting. I would love to 
> optimize the Migration framework. Just need some more points which I can 
> add in my proposed solution to make it more concrete.
> I request fellow developers to please help me with their respective 
> suggestions, thoughts or feedback, so that I may develop a better and 
> practical proposal.
>
> Regards,
> Manav Agarwal
>

-- 
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/af62fe52-96d7-4c95-a9ed-16d16832e001n%40googlegroups.com.

Re: GSoC Proposal: (Migrations) Adapt schema editors to operate from model states instead of fake rendered models.

[Manav Agarwal]

Link for the proposal - 
https://gist.github.com/manav014/9b0feb734e4d140eef1913340602d2ae

On Monday, April 5, 2021 at 8:41:32 AM UTC+5:30 Manav Agarwal wrote:

> I have added the proposed solution in the proposal. 
> I request fellow developers to please help me with their respective 
> suggestions, thoughts or feedback, so that I may develop a better and 
> practical proposal.
>
> Regards,
> Manav Agarwal
>
> On Friday, April 2, 2021 at 3:09:46 AM UTC+5:30 Manav Agarwal wrote:
>
>> Hello everyone,
>> My name is Manav. I’m a Computer Science and Engineering junior at Dr. 
>> A.P.J. Abdul Kalam Technical University in India.
>> I started contributing to Django in October 2020 and have solved many issues 
>> on trac 
>> 
>> .
>> I read through the GSoC Idea List and the Migration topic stood out for 
>> me. I found the idea to adapt schema editors to operate from model states 
>> instead of fake rendered models really interesting.
>> I am working on this for the last 1 month and I have made myself familiar 
>> with the whole migrations framework codebase. I drafted a basic proposal 
>>  in 
>> which I would be updating the complete solution after some discussion to 
>> make the solution more concrete, practical, and effective.
>> The problem with the Migration framework is briefly described in the 
>> proposal 
>>  
>> itself. 
>> After understanding the problem I came up with a few solutions which are 
>> listed below:
>>
>>1. As Suggested by @MarkusH 
>>, A central registry to 
>>store all dependencies in django.apps.registry.Apps
>>
>>Or
>>
>>2. Designing a new metaclass for ModelState just like we have 
>>ModelBase 
>>
>> 
>>  
>>for Model. As then we would be able to use Options 
>>
>> 
>>  
>>with _meta in ModelState which will help in fetching the field 
>>details.
>>
>> Personally, I found Migration Framework damn interesting. I would love to 
>> optimize the Migration framework. Just need some more points which I can 
>> add in my proposed solution to make it more concrete.
>> I request fellow developers to please help me with their respective 
>> suggestions, thoughts or feedback, so that I may develop a better and 
>> practical proposal.
>>
>> Regards,
>> Manav Agarwal
>>
>

-- 
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/6bcbfb8d-f5a3-409c-b5f9-a5faa3f5151en%40googlegroups.com.