Upgrading BpyBuild's Minimum Python Version to Python 3.9

[StandingPadAnimations]

At the moment, BpyBuild's minimum Python version is Python 3.8. Although this is a welcome improvement from the Python 3.7 minimum we had before v0.3.0, there are still a couple of things we want that can only be done through Python 3.9, specifically modern type annotation features.

For BpyBuild, we use type annotations wherever possible, going as far as to disallow untyped functions and expressions that evaluate to Any in Mypy, and although we've had to relax some features using # type: ignore in certain areas, we can say with confidence that the vast majority of BpyBuild's code has proper type annotations and has proper type checking enforced. That's why being able to use modern type annotations is quite important.

Right now, in modern Python, typing for containers (so typing.List, typing.Dict, etc.) are deprecated in favor of the new options (list, dict, etc.) in Python 3.9, through PEP 585. This feature we can sort-of get with from __futures__ import annotations (and we do currently do on the loose-ends branch), but they can't be used with attrs and cattrs (fundamental dependencies in BpyBuild), or even the cast function. As such, we end up with a pretty annoying mix of both in BpyBuild's code, which isn't ideal.

Meanwhile, Union and Optional have been deprecated in favor of x | y and x | None respectively in Python 3.10, through PEP 604. This syntax however is seemingly available in Python 3.9 through __futures__. As we use Union and Optional in many areas of BpyBuild's code, it would be nice to also be able to use this syntax to avoid a painful migration later on.

There is one main pain point, however, in regard to MCprep. MCprep's minimum Python version is Python 3.7 (as used by Blender 2.8), and while BpyBuild doesn't use Python 3.7, the Python 3.8 minimum is meant to be close enough. Updating BpyBuild's minimum Python version will definitely cause inconvenience with virtual environments. Although it wouldn't be preferable, we could perhaps delay this upgrade to a later date (we won't be updating in the near future anyway, the goal is to upgrade by v0.8.0)

[StandingPadAnimations]

@TheDuckCow Curious on your thoughts

[TheDuckCow]

Thanks for outlining this.

The first thing I'd say is that even though we are using deprecated methods, I don't think that's a bad thing really unless we think we're going to be reinventing (again..) building of add-ons here.

Conversely though, we don't / can't use the poetry environment for running of tests anyways, so having different python versions doesn't actually really hamper developmental there, outside of just risking we use the wrong typing in one place or the other. Given that, I'd be ok with moving forward with this - but only after the 3.6 MCprep milestone and 0.4.0 build milestone at the earliest.

I'd like to not complicate the building code further, so best to avoid any clever workarounds and just use the right conventions for the version of Python being targeted as supported.

[StandingPadAnimations]

I agree there isn't really any issues right now as-is since we're currently on Python 3.8, and I don't intend on changing the minimum soon anyway (either 0.4.0 or the version after, which will just be to clean up the code and QoL improvements). I think __futures__ in Python 3.8 is a good start. Yes, there are limitations, but it should reduce the burden of converting types when we eventually do update to Python 3.9.

The only main issue left is that Python 3.8 goes EOL in October, so perhaps we could look into upgrading the minimum to 3.9 next year? (which is a ways away)

[TheDuckCow]

I think that October is a fair milestone for it then, sure.

[StandingPadAnimations]

Slight change of plalns related to the release schedule: BpyBuild 0.4.1 will be pushed to sometime around December or January (since 0.4.1's changes on their own are extrmely minimal) and be released as BpyBuild 0.5, which will mean 0.4 is the last version to use Python 3.8.