APE 10: What is Python support beyond 4.0?

[pllim]

For instance, when are we dropping Python 3.6? Is astropy 5.0 a reasonable release to do so? Where will such decision be documented? Asking for astropy/astropy#10662 .

For that matter, where do we document plans to bump minversions for all the required dependencies for astropy? See https://github.com/astropy/astropy/blob/fecb178391f94eb69eecd67b82d9e00323072719/setup.cfg#L31-L34

Dropping Python 3.6 allows:

• Better annotation support.
• Usage of module level __getattr__.

[bsipocz]

I had the impression that we are joined the other projects with https://numpy.org/neps/nep-0029-deprecation_policy.html

[pllim]

If we did, the APE should be updated? Looking at Numpy's table (see below), we should have dropped Python 3.6 last month but I have no idea how that would translate to our own release schedule. 🤷 (Our current numpy minversion is 1.16 although @mhvk proposed to drop 1.16 for astropy 4.2.)

Date	Python	NumPy
Jan 07, 2020	3.6+	1.15+
Jun 23, 2020	3.7+	1.15+
Jul 23, 2020	3.7+	1.16+
Jan 13, 2021	3.7+	1.17+
Jul 26, 2021	3.7+	1.18+
Dec 26, 2021	3.8+	1.18+
Apr 14, 2023	3.9+	1.18+

[mhvk]

From the table, python 3.7 and numpy 1.16 or 1.17 for 4.2 sound quite reasonable. It would be good to update the APE... But have we even converged on whether or not we can add addenda?? Probably yet another thing that would be good to discuss on the next astropy call.

[pllim]

But have we even converged on whether or not we can add addenda??

Not sure. #60 is still not merged. 🤷

[mhvk]

Cross-link to astropy/astropy#10664 (comment) and following: upgrading astropy and numpy at the same time is not so bad, but python is trickier for users (as it usually is installed via the OS). Moving to python 3.7 still seems fairly reasonable, though. We do have LTS for a reason!

[Cadair]

+1 for NEP 29 at least for CPython.

[mhvk]

Since there seem to be several PRs for which it is important to know whether we raise the minimum version to 3.7, maybe cc @astropy/core-release-maintainers - my sense from the above is that we should have cpython >=3.7 for astropy 4.2.

[pllim]

Given the supposed feature freeze for 4.2 is only a few weeks away, isn't this too sudden? Will we catch downstream packages off-guard?

[mhvk]

@pllim - I thought part of the problem was that downstream cannot have an expectation, since we don't define what the minimum version will be... Given that absence, sticking to NEP 29 seems fairly reasonable - it is meant to be for all of scientific python.

[astrofrog]

I would be ok with following NEP 29 but in that case we should have an addendum to APE 10 along with information about how we handle LTS releases.

[taldcroft]

👍 on following NEP 29, and 👍 on updating APE 10 with an addendum (we do have a date-last-revised field).

[astrofrog]

We should try and converge on #60 as soon as possible before updating APE 10

[taldcroft]

I put in minor comments to #60 and I think it is then ready.

[bsipocz]

I would be ok with following NEP 29 but in that case we should have an addendum to APE 10 along with information about how we handle LTS releases.

We had a situation in the past that the LTS supported older versions on the 3.x series, so at least the precedent is there to support different things. Or do you mean information in case a version is dropped differently for a new LTS?

Anyway, resolving questions like this, whether to follow NEP 29 or in fact, any of the issues came up in e.g. astropy/astropy-project#96 and in related issues would have been good items on a dev telecon. Are those telecons fully dropped now, that the project is funded?

[taldcroft]

I think dev telecons have been a victim of the pandemic (everyone just a bit out of sorts) and not having anyone volunteer to step up and run them. The lack thereof is unrelated to funding AFAIK.

[mhvk]

Like @bsipocz, I think LTS is not a big issue - the minimum version for those should surely stay the same.

The absence of dev telecons is regrettabe if understandable. But for this issue my sense is that there are no strong objections, and an e-mail to astropy-dev to ask for any reasons not to follow NEP 29 might suffice. Shall I send one?

[bsipocz]

The regular telecons ceased to be well before the pandemic, and there wasn't a clear step down (if step down has happened) of running those communicated (and running those were somewhat guarded quite defensively in the past, so no wonder no one randomly jumped in to schedule them.)

I mentioned the funding as the report prepared for the grant explicitly mentions that tasks not taken up by volunteers are funded by the grant. Yet, I see that things that worked got called bottlenecks and have people hired to do them, but the developer telecons did not cross the threshold to be deemed important enough.

[astrofrog]

I agree that finding/funding someone to organise dev telecons should be a priority now. Earlier this year I think the governance discussions dominated available telecon time, but with those telecons not currently ongoing we should definitely be having regular dev calls.

[mhvk]

Indeed, it does seem that organizing the telecons is one of those tasks volunteers are not the best for (I certainly have zero interest or ability myself...), so seconding thirding the (implicit) suggestion to see if that can be part of the paid work.

[bsipocz]

somewhat guarded quite defensively in the past

again, I would have been more than happy to run those, after all I was running the co-working hours experiment for a while, but they had their owner and defensiveness around each time a dev telecon needed to be scheduled.
without a clear let go, no one can reasonably step up. But of course, creating problems and claiming the need to solve them with money is also a valid approach, but it may not be the most sustainable one.

[eteq]

I'd like to ask we move any discussion on the details of resume the dev telecons over to astropy/astropy-project#94 (or a new issue if anyone feels that is too narrow a scope for what they are discussion). The discussion here on this has wandered far from the main point of this issue.

That said, the relevant part is that whether there's a dev telecon or not we want to record any conclusions in this issue (or #63 since I believe that effectively subsumes this!)