Issues representing Python version 3.10 in portfiles

[Ryan Schmidt]

On Oct 19, 2020, at 14:10, Christopher Chavez wrote:

> So far the versions for Python have been able to compact into two-digit strings: e.g. 36 37 38 39. Is the compacted version number for next year's Python 3.10 going to be "310"?
> 
> If so, there is code in portfiles which requires adjustment. Common example:
> 
> set pbranch [string range ${pver} 0 end-1].[string index ${pver} end]
> 
> assumes ${pver} is two-digit; setting ${pver} to "310" causes ${pbranch} to be set to "31.0" rather than "3.10". (I'd much prefer the inverse approach of setting ${pbranch} first, then doing `set pver [join [split ${pbranch} "."] ""]`.)
> 
> Maybe this convention followed Van Rossum's expectation long ago that Python would go directly from 3.9 to 4.0.

The python portgroup contains code for transforming the no-dot form of the branch (which it calls python.version) into the with-dot form of the branch (which it calls python.branch). That code currently does not account for a future 3.10 version but can be fixed in that one place and then benefits all ports that use that portgroup, provided those ports use those existing variables. It doesn't help any ports that manually copied the code for setting such variables.

I agree that it would have been a good idea for the python portgroup to use the with-dot branch as the one that ports set and compute the no-dot branch, rather than the other way around. Other portgroups like perl5-1.0 and php-1.1 already do it that way. We could introduce a new python-1.1 portgroup to fix it, taking the opportunity to also fix the confusing variable names; it will then be a long process of moving all ports over to that new portgroup, but that's fine; the 1.0 and 1.1 portgroups can coexist for as long as is necessary to do the transition.


Whether we also want to change the portfile names from e.g. python39 to python3.9 and from py39-foo to py3.9-foo is a separate matter and probably a much more difficult transition to do. Given how many python module ports there are and how extensively they're used, we might not want to attempt such a rename.