Repository navigation
APE 10: What is Python support beyond 4.0? #62
Description
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__.
Activity
bsipocz commentedon Aug 17, 2020
I had the impression that we are joined the other projects with https://numpy.org/neps/nep-0029-deprecation_policy.html
pllim commentedon Aug 17, 2020
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.)
mhvk commentedon Aug 17, 2020
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 commentedon Aug 17, 2020
Not sure. #60 is still not merged. 🤷
mhvk commentedon Aug 17, 2020
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 commentedon Aug 17, 2020
+1 for NEP 29 at least for CPython.
mhvk commentedon Oct 8, 2020
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 commentedon Oct 8, 2020
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 commentedon Oct 8, 2020
@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 commentedon Oct 8, 2020
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 commentedon Oct 8, 2020
👍 on following NEP 29, and 👍 on updating APE 10 with an addendum (we do have a
date-last-revisedfield).astrofrog commentedon Oct 8, 2020
We should try and converge on #60 as soon as possible before updating APE 10
taldcroft commentedon Oct 8, 2020
I put in minor comments to #60 and I think it is then ready.
bsipocz commentedon Oct 8, 2020
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 commentedon Oct 8, 2020
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 commentedon Oct 8, 2020
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-devto ask for any reasons not to follow NEP 29 might suffice. Shall I send one?bsipocz commentedon Oct 8, 2020
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 commentedon Oct 9, 2020
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 commentedon Oct 9, 2020
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
secondingthirding the (implicit) suggestion to see if that can be part of the paid work.bsipocz commentedon Oct 9, 2020
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 commentedon Oct 16, 2020
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!)