Require python >= 3.11

[korikuzma]

We should follow biocommons / genomic med lab and support the 3 most recent python versions: https://devguide.python.org/versions/. So we should require Python >= 3.11.

This might be a separate issue, but thought I'd bring this up. For the development setup, we require Python 3.12 (https://github.com/ga4gh/vrs-python?tab=readme-ov-file#prerequisites). Since we have CI checks for all Python versions we support, I think we don't need to pin to 3.12.

[melissacline]

I want to take a step back to ask: is this necessary? Because staying on the cutting edge can be a barrier to adoption by users who need to support older software (in the worst case, with functional dependencies that aren't supported in later versions of some external library). Are there features of Python >= 3.11 that are needed?

[korikuzma]

@melissacline Good question. Biocommons supports the 3 most recent Python releases (we're still working on transitioning since Python 3.13 was released in October). I think it's important for us to also require Python >= 3.11 since VRS-Python relies heavily on biocommons dependencies. Once these biocommons packages start requiring Python >= 3.11, VRS-Python will not work on Python <= 3.10.

[melissacline]

@korikuzma , what you say makes sense. @ahwagner , this feels like impetus to go back to the "VRS in a Box" objective. I appreciate that Biocommons doesn't want their software stack to get out of date, but this is another hurdle for new adopters who haven't (or can't) update their own software stack. Maybe a vrs-python docker, coupled with the UTA and SeqRepo dockers?

[melissacline]

And come to think of it, if we're working with dockers for UTA and the SeqRepo REST service, do we need our users to update in concert with BioCommons? Updating is a good idea, but do we need to require it?

[ahwagner]

I agree @melissacline. I think we should focus on making VRS-python 2.0 portable and self-contained as part of our push to disseminate with the VRS 2.0 release announcement. And prioritize that activity over new feature releases. It make sense that as we release new versions of VRS-Python that our dependencies get updated as @korikuzma; but people should be able to readily use older versions of VRS-Python that support older versions of Python and corresponding libraries.