Re: [patch] cygport : update to python 3.9

[Jon Turney <jon.turney@dronecode.org.uk>]

On 03/01/2022 21:42, Marco Atzeri wrote:
> On 03.01.2022 18:37, Jon Turney wrote:
>> On 31/12/2021 10:00, Marco Atzeri wrote:
>>> Attached patch moves "default" from 3.6 to 3.9
> 
>>> Other point:
>>>
>>> As 3.5 was never really deployed, I think we can remove it from the 
>>> distribution.

Agreed.  I have started collecting a list of packages to do a purge of, 
and I'll add those to it.

[...]
> 
> Following is a sort of RFC, so let me know your opinion.
> 
> Currently we have two type of Python packages
> 
> 1) Pure python that exists at max as 2.7 3.6 3.7 3.8 3.9 plus 2 and 3
> 
>     in that case 2/2.7 3/3.6 are EOL;
>     I stopped last year to update the 2.7 and I am thinking to do the
>     same for 3.6 now.
> 
>     I do not see the need to continue to update 3.7, it never become
>     default as we jumped from 3.6 to 3.8 and it is not more
>     active upstream:
>     https://www.python.org/dev/peps/pep-0537/#lifespan
> 
>     We can update the 3.8 and 3.9 while preparing/testing for 3.10
> 
>     source package will continue to use the "python-*" form, while
>     "python3-*" should not be used.

I disagree about the second half of that sentence.

 From a package management point of view:

* being able to script 'install python3, python3-foo' and get the foo 
for the default python is useful

* having the setup remember that python3-foo was installed (causing 
python39-foo to be installed), means when the default python is updated 
from python39 to python3nn, setup will also install python3nn-foo, so 
local scripts with a python3 shebang which 'import foo' continue to work.

I've posted a cygport patch which adjusts cygport to generate these 
python3-foo virtual packages. What do you think about that?

> 2) python packages derived from other packages, where the
>     nomenclature is not uniform:
> 
>     Where we have all variants
>      libxml2          python27-libxml2
>      libxml2          python36-libxml2
>      libxml2          python37-libxml2
>      libxml2          python38-libxml2
> 
>    Only one as I moved from supporting 2 to supporting only 3
>      postgresql       postgresql-plpython
> 
>    To hybrid version
>      openbabel        python2-openbabel   (not updated anymore)
>      openbabel        python38-openbabel
> 
>    I think we should stop to call derived packages "python3-*".
>    Or we use the full version as python38-openbabel or
>    no version at all as python-gdal

I think where the package produces a python binding for a specific 
python version, the package name should have that version (i.e. 
python3x-foo).

> In general
> 
>    We should also stop to pull as dependency "python3"
>    or "python3-devel" as build dependency.
>    Use the full version for dependencies.

I don't think those need to appear in the BUILD_REQUIRES at all.

scallywag is capable of inferring from 'inherit python*' that certain 
python packages are build requirements.

>    Plus use "python3_fix_shebang SCRIPT" for setting the proper
>    interpreter and avoid the issue seen on mercurial and dblatex
>    https://cygwin.com/pipermail/cygwin/2021-December/250282.html
>    I used a cruder version but python3_fix_shebang should do the work