Re: Revisiting Python support for after Django 3.2 LTS

[Carlton Gibson]

Thanks again Tim. I really appreciate your insight.

On Tue, 24 Nov 2020 at 19:07, Tim Graham  wrote:

> That would be a heavy stick whereas there's already been some hesitance
> here to the "carrot" argument of the current policy which restricts older
> Python users to a Django LTS.
> [...]
> I think we should wait a few years to see how Python's annual releases
> interplay with Linux distros before considering making Django's Python
> support policy more aggressive in dropping old Python versions.


Yes, so dropping 3.6 and 3.7 (as per the current policy) for 4.0 is the
“carrot”, and almost as fast as we can go. 樂

It’s a little surprising (is all) — Mariusz and I had been discussing
dropping 3.6 without 3.7 ever coming into mind.

There’s time here for other comments.

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/CAJwKpySkRJ3njY6zv-_0v7CLUC--218kwO-UYMaNcKMgGm3bAg%40mail.gmail.com.

Re: Revisiting Python support for after Django 3.2 LTS

[Tim Graham]

Dropping support for Python versions as they go EOL in existing Django 
releases would be disruptive. Distros "support" Python versions longer than 
the PSF does. If a Django version inadvertently breaks compatibility with 
an old version of Python because we stop testing with it, we'll get bug 
reports about it. It's happened before although I can't remember the exact 
circumstances offhand. It's not good to put users in the position of 
unpredictably being unable to update to a Django security release because 
their Python is old and a security update inadvertently broke 
compatibility. That would be a heavy stick whereas there's already been 
some hesitance here to the "carrot" argument of the current policy which 
restricts older Python users to a Django LTS.

I also thought about something like "support X versions of Python," and 
while I haven't studied the implications in detail, it doesn't strike me as 
significantly better or worse than the alternatives. I think we should wait 
a few years to see how Python's annual releases interplay with Linux 
distros before considering making Django's Python support policy more 
aggressive in dropping old Python versions.
On Tuesday, November 24, 2020 at 3:41:29 AM UTC-5 carlton...@gmail.com 
wrote:

> Hi Tim. 
>
> Thanks for the breakdown, and context on the rationale. 
>
> Do you think we can drop support for Python versions as they go EOL? 
> i.e. for Django 2.2 we COULD HAVE stopped testing against Python 3.5 when 
> it went EOL earlier this year. 
> Given the backport policy, there's no reason to suspect it would break, 
> but we'd not guarantee that.
> (I do worry a bit about saying we support somebody else's EOL software...) 
>
> Assuming that, there's a diagram in PEP 602 (on the Annual Release Cycle) 
> that shows we'd essentially be on the hook for 5 Python versions forever.
> https://www.python.org/dev/peps/pep-0602/#the-testing-matrix
>
> If that's too many, how would something like "Django supports the latest 4 
> versions of Python" sound? 
> This would mean dropping the oldest version ≈12 months before it reached 
> end of life. 
> (We'd have to think about mapping to our 8 month release cycle.)
>
> 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/583eb421-345f-4e19-b713-aeac9a1bca55n%40googlegroups.com.

Request for Comment: settings growth configuring Email Backend.

[Carlton Gibson]

Hi all. 

Can I ask for guidance/comments please? 

Ticket 31885  Update SMTP 
Email Backend to use an SSLContext came in for which there's a PR adding 
`EMAIL_SSL_CAFILE`  settings 
 to match the existing 
EMAIL_USE_SSL  settings. 

The PR looks fine in itself. 

I do wonder about the growth on the number of settings here. 
It looks to my eye to get out of hand.  

An alternate would be subclass EmailBackend, containing your customisations 
there. 

Alternatively we might group setting better than just the `GROUP_` prefix 
(namespaces being one honking great idea). 

Alternatively, "no it's fine, don't worry". 

I mentioned similar about the growth of security headers in a previous 
thread 

. 
Django uses settings. Great! No problem. If they didn't exist, you'd have 
to invent them. But to what extent do we say that new settings are the way 
forward vs having people compose their code with configured components? 

(If I add the words "Technical Board" does that get extra eyes on this? )

Thanks for the input! 

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/a49660ed-8e06-4b21-bf9f-506bbb0b0996n%40googlegroups.com.

Re: Revisiting Python support for after Django 3.2 LTS

[Florian Apolloner]

I think Redhat realized that they have old versions and this is not going 
to fly well during the lifetime of their system. This is why they 
introduced modules in v8 and strongly pushing podman. That said, it is a 
major hurdle for many companies if upstream drops support for $x (be that 
in python, php or whatever). I think this is also one of the reasons why 
containers are so popular. But do we really want to push users that much 
towards containers? Are there any big Django users our there that provide 
RPM packages and could give us some insights?

Cheers,
Florian
On Friday, November 20, 2020 at 11:52:51 PM UTC+1 Tim Allen wrote:

> I often hear Ubuntu thrown around during these discussions, and it is my 
> distro of choice for personal projects. But like many of us, I work at a 
> RedHat / CentOS shop, and trying to maintain a current Python version is a 
> much more difficult proposition. Unfortunately, IUS Community has stopped 
> providing yum-installable versions of Python in an attempt to get EPEL to 
> be more up to date, but that hasn't happened. To get a version of Python 
> greater than 3.6 on RedHat / CentOS, AFAIK, you currently must build from 
> source with altinstall.
>
> I agree with Andrew's statement that we should consider each version. I 
> can see dropping Python 3.5 support - it would allow us to use a feature 
> like f-strings, which improves readability and speed throughout the 
> codebase, and is ubiquitous in Python. But what does dropping Python 3.6 
> support really achieve? Do we need data classes?
>
> I realize there is a need to move forward, especially for wonderful things 
> like better async support. I just ask that we also consider those of us 
> using Django in corporate or academic settings where the pace of upgrading 
> Python is a bit more glacial.
>
> On Thursday, November 19, 2020 at 11:51:29 AM UTC-5 Andrew Godwin wrote:
>
>> I agree we should not be quite so beholden to our existing Python version 
>> policy - that was mostly to get us out of the early 3.x era. Now things are 
>> more stable, I'd support a policy that is much more like "any stable 
>> version of Python currently out there and supported".
>>
>> 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/1e1085e8-a175-4707-be04-cd3073ce7febn%40googlegroups.com.

Re: Revisiting Python support for after Django 3.2 LTS

[Carlton Gibson]

Hi Tim. 

Thanks for the breakdown, and context on the rationale. 

Do you think we can drop support for Python versions as they go EOL? 
i.e. for Django 2.2 we COULD HAVE stopped testing against Python 3.5 when 
it went EOL earlier this year. 
Given the backport policy, there's no reason to suspect it would break, but 
we'd not guarantee that.
(I do worry a bit about saying we support somebody else's EOL software...) 

Assuming that, there's a diagram in PEP 602 (on the Annual Release Cycle) 
that shows we'd essentially be on the hook for 5 Python versions forever.
https://www.python.org/dev/peps/pep-0602/#the-testing-matrix

If that's too many, how would something like "Django supports the latest 4 
versions of Python" sound? 
This would mean dropping the oldest version ≈12 months before it reached 
end of life. 
(We'd have to think about mapping to our 8 month release cycle.)

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/15cd90d9-559f-435d-a07c-724c9b4ac839n%40googlegroups.com.