[patch] cygport : update to python 3.9
Jon Turney
jon.turney@dronecode.org.uk
Sun May 29 15:54:35 GMT 2022
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
More information about the Cygwin-apps
mailing list