On 26.05.2020 01:45, Yaakov Selkowitz wrote:
> On Mon, 2020-05-25 at 06:52 +0200, Marco Atzeri via Cygwin-apps wrote:
>> On 27.04.2020 16:34, Jon Turney wrote:
>>> On 23/04/2020 22:54, Yaakov Selkowitz wrote:
>>>> On Fri, 2020-04-10 at 14:52 +0200, Marco Atzeri via Cygwin-apps wrote:
>>>>> Am 26.03.2020 um 08:19 schrieb Yaakov Selkowitz:
>>>>>> On Thu, 2020-03-26 at 06:54 +0100, Marco Atzeri via Cygwin-apps wrote:
>>>>>>> Am 20.03.2020 um 04:47 schrieb Yaakov Selkowitz:
>>>>>
>>>>> currently we have
>>>>>
>>>>> 119 *python27*
>>>>
>>>> These are fine as is, but they also don't need to be rebuilt or updated
>>>> any more.
>>>>
>>>>> 114 *python36*
>>>>> 115 *python37*
>>>>> 10  *python38*
>>>>
>>>> We don't need to _obsolete or remove python3[67]-* packages, we just
>>>> need to track how many don't have python38-* equivalents yet.
>>>> Obviously that's still the vast majority, since 3.8 just got updated to
>>>> a stable version.
>>>>
>>>> Jon Turney, if a python-foo source package was previously building e.g.
>>>> python27-foo, python36-foo, and python37-foo, and now starts building
>>>> only python37-foo and python38-foo, is calm going to complain?
>>>
>>> Yes, currently it will complain about that ("install packages from
>>> source package '...' have non-unique current versions")
>>>
>>> calm is currently smart enough to exclude old soversions from that
>>> check, so I guess perhaps that it needs to be taught about python27 as
>>> well.
>>>
>>
>> there will be several cases to test;
>> the first I am rebuilding is python-setuptools
>> and it seems there are half of the packages to drop in 46.4.0
>>
>>
>> python-setuptools	python27-setuptools   drop
> 
> I'd like to suggest you make two updates to setuptools, one to the last
> version which supports 2.7 with all Pythons enabled, and then to the
> latest version, dropping 2.7.
> 
>> python-setuptools	python35-setuptools   drop
> 
> 3.5 is still supported upstream and by latest setuptools, why drop
> this?

we are not really supporting 3.5, we have only 8 packages and
stable is 3.6, so I see no reason to go backwards

>> python-setuptools	python36-setuptools
>> python-setuptools	python37-setuptools
>> python-setuptools	python38-setuptools
> 
> No change here, as expected.
> 
>> python-setuptools	python-setuptools-wheel  drop
>>
>> on python-setuptools-wheel, this file is not build/installed anymore
>>
>> usr/share/python-wheels/setuptools-41.2.0-py2.py3-none-any.whl
>>
>> so I guess it was Py2 only
> 
> No; since setuptools dropped Py2 support, they must have stopped
> declaring 'universal' compatibility, so the wheel would now be just
> 'py3' instead of 'py2.py3'.  You don't want to drop this package,
> because it is used by (patched) python3Y venv as well as by python3Y-
> virtualenv.
> 
> OTOH, since the latest setuptools won't work with python27, then
> python27 and python27-virtualenv shouldn't use python-setuptools-wheel
> anymore.  I'd have to look further into the best way to handle that.
> 
> --
> Yaakov
> 

I was moving to the next package after installing setuptools and I got

 >>> python36-pip requires: python36 python38 python38-pip 
ca-certificates python36-setuptools
 >>> python36-pip OBSOLETES: python3-pip
 >>> python37-pip requires: python37 ca-certificates python37-setuptools
 >>> python38-pip requires: python38 ca-certificates python38-setuptools


that is very curious and due to

   usr/bin/pip3

that is a copy of usr/bin/pip3.8

Should I manage "pip3" with alternatives so that is really available
for all python versions ?
I can also override with pip3.7 or pip3.6 to force a fixed default.

Regards
Marco