Add EOL Python warnings

[rmartin16]

What is the problem or limitation you are having?

This idea is a bit half-baked but I'm thinking of adding warnings for users running Briefcase with an EOL Python.

When users are running an EOL Python:

• they may not know it's EOL since they're just using whatever the python/python3 command finds
• they will likely be using outdated versions of Briefcase and Toga

On several occasions after a user explains something weird happening, I notice they are running Python 3.7 and using a newer Python fixes the problem.

Describe the solution you'd like

I guess if we really wanted to, we could replace wheels on PyPI...but I'm going to focus on future releases.

We already have (at least rough) EOL dates for Python versions. So, we can include these and check against the current date when Briefcase runs and warn the user (or more).

This might become a little problematic around newer Python versions. Python 3.13 is scheduled for EOL around 2029/10 but there is no such schedule for 3.14, 3.15, etc....unless you extrapolate the current scheduling. Therefore, it may be difficult to warn someone in the year 2035 that Python 3.14 is EOL and they shouldn't be using Briefcase v0.3.18. Buuuut....I also think excluding such a pathological case from this warning is ok 😆

Describe alternatives you've considered

Keep trying to let people know they are using old Python versions.

Additional context

No response

[freakboy3742]

So - I actually think the problem here is the Briefcase version, not the Python version.

Using an EOL Python is definitely a bad idea - but mostly because of security. Python 3.7 may be EOL, but it still works just as well as it did 8 months ago when it went EOL. That doesn't mean it's a good idea - but anyone trying to use Python 3.7 today is going to start seeing that they can't get the latest version of Pillow, Numpy, or any other major package with a binary component; even pure-Python projects will start adding minimum python requirements when they use new syntactic constructs (like match statements). Someone using Python 3.7 today is definitely making their life difficult, but it's not inherently a problem.

What is a problem is that they must be using a very old version of Briefcase. That means they're missing any number of features - but more importantly bugfixes, most importantly bug fixes introduced because the upstream tools have changed.

So - rather than warning about a stale version of Python, I'd rather warn about a stale version of Briefcase.

Unfortunately, there's no reliable release cadence for Briefcase at present. When we go "1.0", I'm expecting to move to calver, which will help - if you're running version 25.1 in 2026, you're likely on a stale version - but that doesn't help until we adopt calver. It also doesn't protect against "we don't do a release for a year".

The only other alternatives I can see would be:

1. Bake a "use by" date into the code, or
2. Probe PyPI to see if there's a newer release
3. Update the branch templates so they include a warning, or are unusable.

None of those are particularly attractive options to me; (1) is a management hassle; (2) is a network hit that slows down every user just so that a fraction of recalcitrant users (some of whom may have legitimate reasons for staying on old versions) can be warned. And the class of user that is going to get this warning is also the class of user that won't read the damn warning message :-) And (3) is a bit user-hostile for the (admittedly rare) use case of actually needing the old version.

[rmartin16]

So - rather than warning about a stale version of Python, I'd rather warn about a stale version of Briefcase.

I agree; I was using the Python version as a proxy for the Briefcase version. If you're using Python 3.7, you're going to have Briefcase v0.3.9 installed at best. Not perfect by any means but provides a good stopgap....and we already warn users about other bad practices.

As a funny idea....DNS requests are faster than HTTP requests. So, if you add a fake entry to beeware.org to return the version as an IP address, you can provide a bit faster "do i have the latest version" check 😜

[freakboy3742]

So - rather than warning about a stale version of Python, I'd rather warn about a stale version of Briefcase.

I agree; I was using the Python version as a proxy for the Briefcase version. If you're using Python 3.7, you're going to have Briefcase v0.3.9 installed at best. Not perfect by any means but provides a good stopgap....and we already warn users about other bad practices.

I guess that's fair. It's imprecise, and we're still going to have the "people who need to read this are the people who won't read this" problem, but at least we'll have a big yellow warning message to point at.

As a funny idea....DNS requests are faster than HTTP requests. So, if you add a fake entry to beeware.org to return the version as an IP address, you can provide a bit faster "do i have the latest version" check 😜

Yeah... but then we're relying on DNS, and that always goes well 😝

[kaleJohn]

Working on this at Pycon