python 2 check & cleaning

Marco Atzeri marco.atzeri@gmail.com
Mon Jan 18 11:16:51 GMT 2021


On 18.01.2021 08:21, Brian Inglis wrote:
> On 2021-01-17 22:33, Marco Atzeri via Cygwin-apps wrote:
>> Could you please check your packages if they will work with
>> preferred python3.8?
> 
> @ units
> ...
> requires: cygwin findutils libreadline7 python3 python36 python36-requests
> ...
> depends2: cygwin, findutils, libreadline7, python36, python36-requests
> build-depends: autoconf, binutils, coreutils, cygport, cygwin-devel, 
> gawk, gcc-core, grep, libncurses-devel, libreadline-devel, perl_base, 
> python3, python3-devel, python3-requests, sed, texinfo
> 
> $ head -1 `which units_cur`
> #!/usr/bin/python3.6m
> 
> How can I ensure units depends2 and requires, and the script hash-bang 
> uses only the generic python3, python3-devel, python3-requests like 
> build-depends, and avoids using the "current" specific version 36/3.6m?

Hi Brian,

python3-requests for the time being will pull python36-requests.

That is fine for your
   #!/usr/bin/python3.6m

Cygport has hard coded the OBSOLETES, this is something
we need to change in cygport:

 >>> python36-requests OBSOLETES: python3-requests

> And how can I ensure that units_cur is tested using only python38 modules?
> Will the hash-bang override the command line run python38 `which 
> units_cur`?
> 

rebuilding from your source I had

units requires: cygwin findutils libreadline7 python38 python38-requests

It seems the "inherit python3" is pulling the current choice
of my system

$ alternatives --display python3
python3 - status is auto.
  link currently points to /usr/bin/python3.8
/usr/bin/python3.7 - priority 37
/usr/bin/python3.6 - priority 36
/usr/bin/python3.8 - priority 38
Current `best' version is /usr/bin/python3.8.

Regards
Marco


More information about the Cygwin-apps mailing list