[patch] cygport : update to python 3.9

[patch] cygport : update to python 3.9

[Marco Atzeri]

[-- Attachment #1: Type: text/plain, Size: 351 bytes --]

Attached patch moves "default" from 3.6 to 3.9

Additional changes:
  Remove 3.5 from all
  Change future to 3.10


Other point:

As 3.5 was never reall deployed, I think we can remove it from the 
distibution.

As we have a lot of python3-* is obsoleded py python36-*
what is the best way to updated to python39-* when available ?

Regards
Marco





[-- Attachment #2: cygport-python3.patch --]
[-- Type: text/plain, Size: 2488 bytes --]

--- python-wheel.cygclass-bk	2021-12-31 08:53:33.186729100 +0100
+++ python-wheel.cygclass	2021-12-31 10:10:42.372875400 +0100
@@ -60,12 +60,12 @@
 #  inherit python-wheel
 #  DESCRIPTION
 #  A colon-seperated list of version(s) for which this module should be built.
-#  Some aliases are also accepted:
-#  * all: all supported 3.y versions (currently: 3.5 through 3.8)
-#  * future: the default and upcoming 3.y versions (currently: 3.7, 3.8)
-#  * default: the default 3.y version(s) (currently: 3.7, 3.8)
+#  Some aliases are also accepted (at 2021 Dec 31st):
+#  * all: all supported 3.y versions (currently: 3.6 through 3.9)
+#  * future: the default and upcoming 3.y versions (currently: 3.9, 3.10)
+#  * default: the default 3.y version(s) (currently: 3.8, 3.9)
 #  * 2: the default 2.x version (permanently 2.7)
-#  * 3: the default 3.x version (currently: 3.8)
+#  * 3: the default 3.x version (currently: 3.9)
 #  This variable must be defined before inheriting python-wheel.cygclass.
 #  If undefined, "default" is assumed.
 #  NOTES
@@ -93,11 +93,11 @@
 for ver in ${PYTHON_WHEEL_VERSIONS//:/ }
 do
 	case "${ver}" in
-	all)		_tmp_wheel_v+=3.5:3.6:3.7:3.8: ;;
-	future)		_tmp_wheel_v+=3.7:3.8: ;;
-	default)	_tmp_wheel_v+=3.7:3.8: ;;
+	all)		_tmp_wheel_v+=3.6:3.7:3.8:3.9: ;;
+	future)		_tmp_wheel_v+=3.9:3.10: ;;
+	default)	_tmp_wheel_v+=3.8:3.9: ;;
 	2)		_tmp_wheel_v+=2.7: ;;
-	3)		_tmp_wheel_v+=3.8: ;;
+	3)		_tmp_wheel_v+=3.9: ;;
 	*)		_tmp_wheel_v+=$ver: ;;
 	esac
 done
@@ -128,7 +128,7 @@
 		# and MUST NOT be updated when defaults change
 		case ${ver} in
 		2.7)	declare -g python27_${PYTHON_WHEEL_NAME//[-\.]/_}_OBSOLETES="python-${PYTHON_WHEEL_NAME} python2-${PYTHON_WHEEL_NAME}" ;;
-		3.6)	declare -g python36_${PYTHON_WHEEL_NAME//[-\.]/_}_OBSOLETES="python3-${PYTHON_WHEEL_NAME}" ;;
+		3.9)	declare -g python39_${PYTHON_WHEEL_NAME//[-\.]/_}_OBSOLETES="python3-${PYTHON_WHEEL_NAME}" ;;
 		esac
 		declare -g python${ver/.}_${PYTHON_WHEEL_NAME//[-\.]/_}_CONTENTS="usr/lib/python${ver}/site-packages/ usr/share/doc/python${ver/.}-${PYTHON_WHEEL_NAME}"
 	done
@@ -195,7 +195,7 @@
 		# ENSUREPIP_OPTIONS=install: pipX, pipX.Y, easy_install-X.Y
 
 		case ${ver} in
-		2.7|3.8) export ENSUREPIP_OPTIONS="install" ;;
+		2.7|3.9) export ENSUREPIP_OPTIONS="install" ;;
 		*) export ENSUREPIP_OPTIONS="altinstall" ;;
 		esac
 		pip${ver} install -I dist/${whl} --root ${D} --prefix /usr --no-compile --no-deps --no-warn-script-location || error "pip${ver} install failed"

Re: [patch] cygport : update to python 3.9

[Jon Turney]

On 31/12/2021 10:00, Marco Atzeri wrote:
> Attached patch moves "default" from 3.6 to 3.9
> 
> Additional changes:
>   Remove 3.5 from all
>   Change future to 3.10
> 

Thanks.

> 
> Other point:
> 
> As 3.5 was never really deployed, I think we can remove it from the 
> distribution.
> 
> As we have a lot of python3-* is obsoleted py python36-*
> what is the best way to updated to python39-* when available ?

Good question.  Note the comment before this hunk:

> @@ -128,7 +128,7 @@
>                 # and MUST NOT be updated when defaults change
>                 case ${ver} in
>                 2.7)    declare -g python27_${PYTHON_WHEEL_NAME//[-\.]/_}_OBSOLETES="python-${PYTHON_WHEEL_NAME} python2-${PYTHON_WHEEL_NAME}" ;;
> -               3.6)    declare -g python36_${PYTHON_WHEEL_NAME//[-\.]/_}_OBSOLETES="python3-${PYTHON_WHEEL_NAME}" ;;
> +               3.9)    declare -g python39_${PYTHON_WHEEL_NAME//[-\.]/_}_OBSOLETES="python3-${PYTHON_WHEEL_NAME}" ;;
>                 esac
>                 declare -g python${ver/.}_${PYTHON_WHEEL_NAME//[-\.]/_}_CONTENTS="usr/lib/python${ver}/site-packages/ usr/share/doc/python${ver/.}-${PYTHON_WHEEL_NAME}"
>         done

which in full reads:

"
		# these were 2&3 at the time of the XY-version split,
		# and MUST NOT be updated when defaults change
"

So it seems to me that either that hunk is wrong, or that comment needs 
updating.

I'm not sure what the intent is here.

Re: [patch] cygport : update to python 3.9

[Marco Atzeri]

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.
>>
>> As we have a lot of python3-* is obsoleted py python36-*
>> what is the best way to updated to python39-* when available ?
> 
> Good question.  Note the comment before this hunk:
> 
>> @@ -128,7 +128,7 @@
>>                 # and MUST NOT be updated when defaults change
>>                 case ${ver} in
>>                 2.7)    declare -g 
>> python27_${PYTHON_WHEEL_NAME//[-\.]/_}_OBSOLETES="python-${PYTHON_WHEEL_NAME} 
>> python2-${PYTHON_WHEEL_NAME}" ;;
>> -               3.6)    declare -g 
>> python36_${PYTHON_WHEEL_NAME//[-\.]/_}_OBSOLETES="python3-${PYTHON_WHEEL_NAME}" 
>> ;;
>> +               3.9)    declare -g 
>> python39_${PYTHON_WHEEL_NAME//[-\.]/_}_OBSOLETES="python3-${PYTHON_WHEEL_NAME}" 
>> ;;
>>                 esac
>>                 declare -g 
>> python${ver/.}_${PYTHON_WHEEL_NAME//[-\.]/_}_CONTENTS="usr/lib/python${ver}/site-packages/ 
>> usr/share/doc/python${ver/.}-${PYTHON_WHEEL_NAME}"
>>         done
> 
> which in full reads:
> 
> "
>          # these were 2&3 at the time of the XY-version split,
>          # and MUST NOT be updated when defaults change
> "
> 
> So it seems to me that either that hunk is wrong, or that comment needs 
> updating 
> 
> I'm not sure what the intent is here.

I guess Yaakov was thinking of python3 as the older alias of python36, 
and **only** for that. As Python2 is the older alias of python27.
In that case make sense to leave as the comment says.

Probably I should write entries in the FAQ and documentation
to clarify this scope.

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.

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

In general

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

   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


Regards
Marco

Re: [patch] cygport : update to python 3.9

[Marco Atzeri]

[-- Attachment #1: Type: text/plain, Size: 882 bytes --]

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
>>
>> Additional changes:
>>   Remove 3.5 from all
>>   Change future to 3.10
>>
> 
> Thanks.
> 
>>
>> Other point:
>>
>> As 3.5 was never really deployed, I think we can remove it from the 
>> distribution.
>>
>> As we have a lot of python3-* is obsoleted py python36-*
>> what is the best way to updated to python39-* when available ?
> 
> Good question.  Note the comment before this hunk:
> 
...>
> which in full reads:
> 
> "
>          # these were 2&3 at the time of the XY-version split,
>          # and MUST NOT be updated when defaults change
> "
> 
> So it seems to me that either that hunk is wrong, or that comment needs 
> updating.
> 
> I'm not sure what the intent is here.

attached 2nd version removing that item

[-- Attachment #2: cygport-python3-v2.patch --]
[-- Type: text/plain, Size: 1895 bytes --]

--- python-wheel.cygclass-bk	2021-12-31 08:53:33.186729100 +0100
+++ python-wheel.cygclass	2021-12-31 10:10:42.372875400 +0100
@@ -60,12 +60,12 @@
 #  inherit python-wheel
 #  DESCRIPTION
 #  A colon-seperated list of version(s) for which this module should be built.
-#  Some aliases are also accepted:
-#  * all: all supported 3.y versions (currently: 3.5 through 3.8)
-#  * future: the default and upcoming 3.y versions (currently: 3.7, 3.8)
-#  * default: the default 3.y version(s) (currently: 3.7, 3.8)
+#  Some aliases are also accepted (at 2021 Dec 31st):
+#  * all: all supported 3.y versions (currently: 3.6 through 3.9)
+#  * future: the default and upcoming 3.y versions (currently: 3.9, 3.10)
+#  * default: the default 3.y version(s) (currently: 3.8, 3.9)
 #  * 2: the default 2.x version (permanently 2.7)
-#  * 3: the default 3.x version (currently: 3.8)
+#  * 3: the default 3.x version (currently: 3.9)
 #  This variable must be defined before inheriting python-wheel.cygclass.
 #  If undefined, "default" is assumed.
 #  NOTES
@@ -93,11 +93,11 @@
 for ver in ${PYTHON_WHEEL_VERSIONS//:/ }
 do
 	case "${ver}" in
-	all)		_tmp_wheel_v+=3.5:3.6:3.7:3.8: ;;
-	future)		_tmp_wheel_v+=3.7:3.8: ;;
-	default)	_tmp_wheel_v+=3.7:3.8: ;;
+	all)		_tmp_wheel_v+=3.6:3.7:3.8:3.9: ;;
+	future)		_tmp_wheel_v+=3.9:3.10: ;;
+	default)	_tmp_wheel_v+=3.8:3.9: ;;
 	2)		_tmp_wheel_v+=2.7: ;;
-	3)		_tmp_wheel_v+=3.8: ;;
+	3)		_tmp_wheel_v+=3.9: ;;
 	*)		_tmp_wheel_v+=$ver: ;;
 	esac
 done
@@ -195,7 +195,7 @@
 		# ENSUREPIP_OPTIONS=install: pipX, pipX.Y, easy_install-X.Y
 
 		case ${ver} in
-		2.7|3.8) export ENSUREPIP_OPTIONS="install" ;;
+		2.7|3.9) export ENSUREPIP_OPTIONS="install" ;;
 		*) export ENSUREPIP_OPTIONS="altinstall" ;;
 		esac
 		pip${ver} install -I dist/${whl} --root ${D} --prefix /usr --no-compile --no-deps --no-warn-script-location || error "pip${ver} install failed"

Re: [patch] cygport : update to python 3.9

[Jon Turney]

On 04/01/2022 16:05, 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
>>>
>>> Additional changes:
>>>   Remove 3.5 from all
>>>   Change future to 3.10
>>>
>>
>> Thanks.
>>
>>>
>>> Other point:
>>>
>>> As 3.5 was never really deployed, I think we can remove it from the 
>>> distribution.
>>>
>>> As we have a lot of python3-* is obsoleted py python36-*
>>> what is the best way to updated to python39-* when available ?
>>
>> Good question.  Note the comment before this hunk:
>>
> ...>
>> which in full reads:
>>
>> "
>>          # these were 2&3 at the time of the XY-version split,
>>          # and MUST NOT be updated when defaults change
>> "
>>
>> So it seems to me that either that hunk is wrong, or that comment 
>> needs updating.
>>
>> I'm not sure what the intent is here.
> 
> attached 2nd version removing that item

Thanks. Applied.

Whilst testing this, I note in passing that /usr/bin/pip3.9 has a
'/usr/bin/python' shebang.

So it fails to work correctly (acting as pip3.8 ?) after 
'usr/sbin/alternatives --set python /usr/bin/python3.8'

Re: [patch] cygport : update to python 3.9

[Marco Atzeri]

On 08.01.2022 17:32, Jon Turney wrote:

> 
> Whilst testing this, I note in passing that /usr/bin/pip3.9 has a
> '/usr/bin/python' shebang.
> 
> So it fails to work correctly (acting as pip3.8 ?) after 
> 'usr/sbin/alternatives --set python /usr/bin/python3.8'

thanks for the advice

upstream changed the behaviour between 3.8 and 3.9
and it seems I need to respin some packages

$ for i in /usr/bin/*3.9 ;do  head -n1 $i ; done | grep "9$" |wc -l
81

$ for i in /usr/bin/*3.9 ;do  head -n1 $i ; done | grep "n$" |wc -l
5

Re: [patch] cygport : update to python 3.9

[Jon Turney]

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

Re: [patch] cygport : update to python 3.9

[Hamish McIntyre-Bhatty]

On 31/12/2021 10:00, Marco Atzeri wrote:
> Attached patch moves "default" from 3.6 to 3.9
> 
> Additional changes:
>   Remove 3.5 from all
>   Change future to 3.10
> 
> 
> Other point:
> 
> As 3.5 was never reall deployed, I think we can remove it from the 
> distibution.
> 
> As we have a lot of python3-* is obsoleded py python36-*
> what is the best way to updated to python39-* when available ?
> 
> Regards
> Marco
> 
> 
> 
> 

Just noticed this. I'll update my packages to rebuild against Python 3.10.

I'm also going to try to get wxWidgets 3.1 (and thus newer wxPython) 
working again soon, but I might need some help debugging the test suite 
if it still misbehaves.

I guess that means I'm now building wxWidgets and wxPython for 4 
different versions of Python on 64-bit and 32-bit. I'll be glad when 
32-bit builds go away, it takes so long to do these builds, even on a 
Ryzen 3600.

Hamish

Re: [patch] cygport : update to python 3.9

[Marco Atzeri]

On 29.06.2022 17:36, Hamish McIntyre-Bhatty wrote:
> On 31/12/2021 10:00, Marco Atzeri wrote:
>> Attached patch moves "default" from 3.6 to 3.9
>>
>> Additional changes:
>>   Remove 3.5 from all
>>   Change future to 3.10
>>
>>
>> Other point:
>>
>> As 3.5 was never reall deployed, I think we can remove it from the 
>> distibution.
>>
>> As we have a lot of python3-* is obsoleded py python36-*
>> what is the best way to updated to python39-* when available ?
>>
>> Regards
>> Marco
>>
>>
>>
>>
> 
> Just noticed this. I'll update my packages to rebuild against Python 3.10.

We have not yet 3.10.
I was planning to deply it in July

> 
> I'm also going to try to get wxWidgets 3.1 (and thus newer wxPython) 
> working again soon, but I might need some help debugging the test suite 
> if it still misbehaves.
> 
> I guess that means I'm now building wxWidgets and wxPython for 4 
> different versions of Python on 64-bit and 32-bit. I'll be glad when 
> 32-bit builds go away, it takes so long to do these builds, even on a 
> Ryzen 3600.

Imagine building on a Laptop with i5-8250U CPU @ 1.60GHz
;-)

All fork intensive builds  are a nightmare ..


> Hamish

Regards
MArco

Re: [patch] cygport : update to python 3.9

[Hamish McIntyre-Bhatty]

On 29/06/2022 16:46, Marco Atzeri wrote:
> On 29.06.2022 17:36, Hamish McIntyre-Bhatty wrote:
>> On 31/12/2021 10:00, Marco Atzeri wrote:
>>> Attached patch moves "default" from 3.6 to 3.9
>>>
>>> Additional changes:
>>>   Remove 3.5 from all
>>>   Change future to 3.10
>>>
>>>
>>> Other point:
>>>
>>> As 3.5 was never reall deployed, I think we can remove it from the 
>>> distibution.
>>>
>>> As we have a lot of python3-* is obsoleded py python36-*
>>> what is the best way to updated to python39-* when available ?
>>>
>>> Regards
>>> Marco
>>>
>>>
>>>
>>>
>>
>> Just noticed this. I'll update my packages to rebuild against Python 
>> 3.10.
> 
> We have not yet 3.10.
> I was planning to deply it in July
> 
>>
>> I'm also going to try to get wxWidgets 3.1 (and thus newer wxPython) 
>> working again soon, but I might need some help debugging the test 
>> suite if it still misbehaves.
>>
>> I guess that means I'm now building wxWidgets and wxPython for 4 
>> different versions of Python on 64-bit and 32-bit. I'll be glad when 
>> 32-bit builds go away, it takes so long to do these builds, even on a 
>> Ryzen 3600.
> 
> Imagine building on a Laptop with i5-8250U CPU @ 1.60GHz
> ;-)
> 
> All fork intensive builds  are a nightmare ..
> 
Ouch! I do not envy you. That said, this is pretty impressive for a 
laptop chip: 
https://cpu.userbenchmark.com/Compare/Intel-Core-i5-8250U-vs-AMD-Ryzen-5-3600/m338266vs4040

It's not that far off the 3600, apparently. I'm slightly dubious about 
the benchmarks there, but maybe the 3600 isn't quite as amazing as I 
thought if they are accurate.

Hamish

Re: [patch] cygport : update to python 3.9

[Hamish McIntyre-Bhatty]

On 29/06/2022 16:36, Hamish McIntyre-Bhatty wrote:
> On 31/12/2021 10:00, Marco Atzeri wrote:
>> Attached patch moves "default" from 3.6 to 3.9
>>
>> Additional changes:
>>   Remove 3.5 from all
>>   Change future to 3.10
>>
>>
>> Other point:
>>
>> As 3.5 was never reall deployed, I think we can remove it from the 
>> distibution.
>>
>> As we have a lot of python3-* is obsoleded py python36-*
>> what is the best way to updated to python39-* when available ?
>>
>> Regards
>> Marco
>>
>>
>>
>>
>
> Just noticed this. I'll update my packages to rebuild against Python 3.10.
>
> I'm also going to try to get wxWidgets 3.1 (and thus newer wxPython) 
> working again soon, but I might need some help debugging the test 
> suite if it still misbehaves.
>
> I guess that means I'm now building wxWidgets and wxPython for 4 
> different versions of Python on 64-bit and 32-bit. I'll be glad when 
> 32-bit builds go away, it takes so long to do these builds, even on a 
> Ryzen 3600.
>
> Hamish

Correction - when Python 3.10 is available in Cygwin, I'll rebuild my 
packages against it.

Hamish

Re: [patch] cygport : update to python 3.9

[Jon Turney]

On 29/05/2022 16:54, Jon Turney wrote:
>>
>> 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?

I've released a cygport 0.35.2 with that patch [1] applied.

Please let me know if it causes you problems.

(It also fixes an issue where the presence of a python3 shebang wasn't 
correctly detected as a dependency on the python3 package due to python3 
being a symlink now)

[1] https://cygwin.com/pipermail/cygwin-apps/2022-May/042051.html

Re: [patch] cygport : update to python 3.9

[Marco Atzeri]

On 03.07.2022 14:22, Jon Turney wrote:
> On 29/05/2022 16:54, Jon Turney wrote:
>>>
>>> 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?
> 
> I've released a cygport 0.35.2 with that patch [1] applied.
> 
> Please let me know if it causes you problems.
> 
> (It also fixes an issue where the presence of a python3 shebang wasn't 
> correctly detected as a dependency on the python3 package due to python3 
> being a symlink now)
> 
> [1] https://cygwin.com/pipermail/cygwin-apps/2022-May/042051.html
> 

Thanks Jon

appreciated.

I will start to refresh python packages,
as soon I finish the current run to update some of the other stuff
that I left behind in the first half of the year.

Regards
Marco