Re: Warning in documentation about filtering queryset in ClassBasedViews

2022-10-30 Thread danigayo...@gmail.com
I thought that it would a good idea to point this because it is a bug that 
you will not catch until production stage, but I guess time dependant 
queries are prone to this and require experience.

After reading your comments I realize this is more a python problem than a 
Django one, as both of you said.

Thank you for your feedback on this


On Sunday, 30 October 2022 at 00:38:50 UTC+2 Adam Johnson wrote:

> I'm inclined to agree with David here. This is a “understanding Python” 
> thing. We can’t feasibly add documentation warnings everywhere such a 
> mistake could be made.
>
> On Sat, Oct 29, 2022 at 8:00 PM David Sanders  
> wrote:
>
>> Hi Daniel,
>>
>> I don't think a warning is necessary here as it's fairly standard Python.
>>
>> To explain: the timezone.now() is evaluated at module level – ie only 
>> once when the Python module is imported – which explains the behaviour that 
>> you're experiencing.
>>
>> If you like you can submit a documentation PR with some suggestions but 
>> others may also doubt the value of adding a warning given that the very 
>> next section explains how to do dynamic filtering. Personally I think by 
>> the time you get to advanced Django such as this, Python experience is 
>> assumed :)
>>
>> Regards,
>> David
>>
>> On Sun, 30 Oct 2022 at 00:02, Daniel Gayoso González  
>> wrote:
>>
>>> Hello,
>>>
>>> Following the example in 
>>> https://docs.djangoproject.com/en/4.1/topics/class-based-views/generic-display/#viewing-subsets-of-objects
>>>  
>>> I tried the following
>>>
>>> class BookListView(ListView):
>>> model = Book
>>> queryset = Book.objects.filter(publication_date__lte=timezone.now())
>>>
>>> I found that this code snippet to retrieve only books that has the 
>>> publication date before today (assuming that could be books with 
>>> publication date in the future) not work as I would expected. 
>>>
>>> After some digging, I found that timezone.now() it's cached when server 
>>> starts up (in a production environment), so this query filter by the date 
>>> the server was started. So the solution is to use a dynamic filtering. 
>>>
>>> Could be a good idea to include some warning about this in the 
>>> documentation?
>>>
>>> Thanks,
>>> Daniel
>>>
>>> -- 
>>> 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/CAHLCT5d3Dz3KTfpxhLQAUZjruhRLgb_XKbUKdv7VgHW_-VVfCg%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-develop...@googlegroups.com.
>>
> To view this discussion on the web visit 
>> https://groups.google.com/d/msgid/django-developers/CADyZw-59A5U0pLOuZ%2BxdfHp%3Dq%3Ddwgw%2BG_GFaRYQAxfdytX6%2B5Q%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/ce97c396-e563-4cbd-aa8c-23b9c8a5e481n%40googlegroups.com.


Re: #21978 include production-ready web server

2022-10-30 Thread Florian Apolloner
Hi Peter,

On Saturday, October 29, 2022 at 6:07:16 PM UTC+2 pe...@lincolnloop.com 
wrote:

> Since you asked for feedback, I'll tell you what I'd do differently (and 
>> this is also a sign that production environment vary widely).
>>
>
> Production environments do vary widely, but I don't think that should stop 
> us from providing defaults that are one-size-fits-most. startproject 
> already does this and users are welcome to adjust it how they see fit.
>

Agreed, I should have written this better. I expect there to be plenty of 
different opinions on this topic and it might be hard to figure out the 
one-size-fits-most without being to limiting.
 

> * As soon as health checks check something aside from simply returning a 
>> 200 status code I'd want to be able to limit access to them
>>
>
> Yep, that seems reasonable. Although depending on the level of failure, 
> you may not be able to log in to see them. Starting with just a view that 
> responds with a 200 is reasonable.
>

Sure and with limiting access I was more thinking about source IPs than 
actual logins (ie open health endpoint to the internal network from which 
the loadbalancer connects)
  

>  * I do hate `DJANGO_ENV` but I guess there is no way around it. Currently 
>> my projects often piggy-back on DEBUG but that can be rather hard from time 
>> to time
>>
>
> I'm open to other suggestions here, but am kind of in the same boat. There 
> may be times when you briefly want DEBUG=True in a non-public deployed 
> environment or DEBUG=False in a development environment. Overloading that 
> makes those scenarios a challenge.
>

Jupp, that is also the reason why I am in a love/hate relationship with it 
:)
 

>  * I prefer settings in settings files (ini/yaml/toml) as opposed to env 
>> variables that leak down the whole process-tree. django-environ does 
>> support this; that said there are other options like dynaconf which also 
>> support hashicorp vault which is a massive plus imo. Just being able to 
>> utilize vault for free from every django application out there would be 
>> stellar.
>>
>
> I'm 100% in agreement here. I wrote goodconf [1] for this before I knew 
> about dynaconf which does a lot of the same things. I would love to see 
> Django adopt a split between "settings" (which I see as things that don't 
> change across environments) and "configuration" (things that you set per 
> environment). I did switch to django-environ's FileAwareEnv [2] which 
> allows loading from files, but not in the yaml./toml sense. I didn't go all 
> in here because I felt like it was a more controversial stance and at the 
> end of the day, you probably still need to support environment variables 
> because many (most?) PaaS providers don't have support for files like that.
>

Yes, being able to override stuff via env variables should probably be 
always allowed. And as long as we do have a "schema" of some kind (be that 
via config.get_bool or typing annotation on a configuration object) it is 
also relatively easy to convert env variables to their correct form (ie 
boolean).

With the goal of getting something merged into Django eventually, I felt 
> like environment variables were the lowest bar. We have precedence for 
> loading from environment variables with DJANGO_SETTINGS_MODULE. Do you 
> think a more full-featured library like dynaconf would make it harder to 
> push some of this upstream? Users that want to use dynaconf or goodconf or 
> whatever can still edit their settings and use those like they do today.
>

Yes and no. A 3rd party dependency will make it certainly harder to get 
this merged upstream. On the other hand I wouldn't want to support env 
variables only in the first iteration if that makes adding support for 
"properly" typed schemes (yaml/toml) harder in the future. From a viability 
point I'd like to see that we have an API that can handle hierarchical 
typed config and env variables. If we get that right the reasons to use 
something else will be rather small I guess. 
 
> Had another thought here... what about providing a pluggable 
configuration backend? Django could ship with some native backends like 
environment variables and toml (when it's available). Third party packages 
could provide Vault, secret files, etc. Same as how storages currently 
works and how you can easily drop in something like django-storages.

Yes, the main question though is how the api contract would look like and 
how we are going to "solve" the chicken egg problem of how those backends 
are activated? We cannot really put `SETTING_LOADERS = 
["django.settings.loaders.env", "django.settings.loader.toml"]` into a 
`settings.py` file and then use `config.get("DATABASE_URL")` just below to 
use the DATABASE_URL. So like `DJANGO_SETTINGS_MODULE` this would be 
something that has to be in an env var before Django starts. But I guess 
that would mostly be okay and projects might be able to pass their own 
loaders to `django.setup()` or configure 

Re: #21978 include production-ready web server

2022-10-30 Thread Florian Apolloner
Hi Tobias,

On Sunday, October 30, 2022 at 2:02:36 AM UTC+2 tob...@caktusgroup.com 
wrote:

> Regarding DJANGO_ENV, why not ship the template with two settings files 
> and use the existing DJANGO_SETTINGS_MODULE, instead of adding a new 
> environment variable?
>

That is certainly one way to do it and probably the most controversial 
point. Ie what does DJANGO_ENV=dev|staging|prod offer over 
`DJANGO_SETTINGS_MODULE=your_project.settings.dev|staging|prod`

Maybe that would be controversial too, I'm not sure, but perhaps less so 
> than introducing a new paradigm? In any event, perhaps a pluggable backend 
> would allow everyone to be happy, or very nearly so... 😅
>

If we can come up with a reasonable API :) I wonder if a setuptools 
entrypoint to automatically enable your backend solely by installing it 
alongside the product would be one way to allow for easy customization… We 
might need two things to get this all started: An documented API contract 
that we can discuss and also a set of usecases that we do want to allow?

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/1e0a0540-fcfa-45b0-bedc-f213aab9b267n%40googlegroups.com.


Re: Draft Steering Council DEP

2022-10-30 Thread James Bennett
On Wed, Oct 26, 2022 at 4:34 PM Andrew Godwin  wrote:

> I have copied in the DSF Members mailing list as it is a
> governance-related DEP, but if we could keep all discussion on the thread
> in the Django Developers mailing list, as per DEP 0001, that would be great.
>

My main concern remains the thing I've been saying repeatedly in the other
thread: how does this actually solve a problem that Django is facing right
now?

We've established that the Technical Board was not carrying out its duties.
There's also been a claim advanced that probably there is not a replacement
slate of board members who would step up and have the capacity to do what
DEP 10 asks.

So, either this new DEP is intended to be a slight clarification of the
Technical Board's role, in which case I don't see how saying "same as
before, but this time we actually expect you to do the thing" solves the
issue. Or it's intended to be a first step toward a more active group, in
which case I don't see how it can succeed given that a lower required level
of activity has already failed.

I also have concerns with the "Steering Council" name. In Python's case
it's something resembling Django's old technical board, which was made up
of core devs elected by core devs (technically Python does it as "must be
nominated by a core dev", not "must be a core dev", but in practice it
makes little difference). I don't want to create the impression that
Django's governance looks even a little bit like that, because it doesn't
look like 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-developers+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CAL13Cg-gULvacpiR6y8ZM89FKHeatoaaLZcj0Vrx9gPqGXG-XA%40mail.gmail.com.


Re: Draft Steering Council DEP

2022-10-30 Thread Andrew Godwin


On Sun, Oct 30, 2022, at 10:42 PM, James Bennett wrote:
> On Wed, Oct 26, 2022 at 4:34 PM Andrew Godwin  wrote:
>> __
>> 
>> I have copied in the DSF Members mailing list as it is a governance-related 
>> DEP, but if we could keep all discussion on the thread in the Django 
>> Developers mailing list, as per DEP 0001, that would be great.
> 
> My main concern remains the thing I've been saying repeatedly in the other 
> thread: how does this actually solve a problem that Django is facing right 
> now?

By widening the set of people who can run for the Board/Council.

> 
> We've established that the Technical Board was not carrying out its duties. 
> There's also been a claim advanced that probably there is not a replacement 
> slate of board members who would step up and have the capacity to do what DEP 
> 10 asks.
> 
> So, either this new DEP is intended to be a slight clarification of the 
> Technical Board's role, in which case I don't see how saying "same as before, 
> but this time we actually expect you to do the thing" solves the issue. Or 
> it's intended to be a first step toward a more active group, in which case I 
> don't see how it can succeed given that a lower required level of activity 
> has already failed.

It is intended to allow for a more active group by giving us a wider set of 
candidates who can run and thus a higher chance of people being on the 
Board/Council who want to be that active.

Andrew

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/347c6859-5315-45ff-80e6-5480b99e95a7%40app.fastmail.com.