Python packaging policy?

Python packaging policy?

[Oleksandr Gavenko]

I figured it out myself that I have to avoid "python3-*" packages and instead
to work with "python36-*" or "python38-*" as "python3-*" packages are marked
as "category: _obsolete" in setup.bz2.

Are there any docs that describes policy for python packages in Cygwin?

I had experience with https://www.debian.org/doc/packaging-manuals/python-policy/
That document had answers to the most questions.

I tried to search for similar information under:

/usr/share/doc/
/usr/share/doc/Cygwin

and in

git://cygwin.com/git/cygwin-htdocs.git

and haven't succeeded.

I'm interested in a package naming/versioning schema, a migration path across
Python releases and the way of "pip install" to live in harmony with Cygwin.

I don't insist on anything particular but some "official" generic guide how to
cook Python in Cygwin would be helpful.

-- 
http://defun.work/

Re: Python packaging policy?

[Marco Atzeri]

On 20.01.2021 00:02, Oleksandr Gavenko via Cygwin wrote:
> I figured it out myself that I have to avoid "python3-*" packages and instead
> to work with "python36-*" or "python38-*" as "python3-*" packages are marked
> as "category: _obsolete" in setup.bz2.
> 
> Are there any docs that describes policy for python packages in Cygwin?
> 
> I had experience with https://www.debian.org/doc/packaging-manuals/python-policy/
> That document had answers to the most questions.

Hi Ole,
unfortunately not.
We have not the bandwith to publish official documents as Debian.
As you can see, that document is signed by all the maintainers that
are probably working with python packages.
The current team in Cygwin is one, and I took over from the previous
maintainer when he decided to retire from the project.

I addition Cygwin is a rolling distro so we need to
maintanin some compatibility with the past as we evolve.

> I tried to search for similar information under:
> 
> /usr/share/doc/
> /usr/share/doc/Cygwin
> 
> and in
> 
> git://cygwin.com/git/cygwin-htdocs.git
> 
> and haven't succeeded.
> 
> I'm interested in a package naming/versioning schema, a migration path across
> Python releases and the way of "pip install" to live in harmony with Cygwin.
> 
> I don't insist on anything particular but some "official" generic guide how to
> cook Python in Cygwin would be helpful.

As you can seen from the several python announcements on the
"cygwin-announce" mailing list

https://sourceware.org/pipermail/cygwin-announce/

------------------------------------------------------------
starting from April/June 2020 the work in progress is:

-) update python-2.7, python-3.6, 3.7 and 3.8 at last versions

python-2.7 is officially dead (EOL) upstream so only minor
maintance is performed to "python27-*" packages

python-3.5 is not updated anymore and will be removed in the future.

-) move the meta-package python3 to pull python 3.8 instead of 3.6

The retiring of python 3.6 is not too far, and some subpackages
do not build anymore with it asking for at least 3.7.

-) upload the "python38-*" for the majority of the subpackages
most has been already done.

Currently there are 158 / 159 / 122 packages for python 3.6/3.7/3.8
and most of the difference is in obsoletes packages.

-) work for python 3.9 will start after the rollout of 3.8 is completed.
Probably a summer vacation excercise :-)

-) check the packages still using python 2 and move the major ones to 
3.8 (possibly)

https://sourceware.org/pipermail/cygwin-apps/2021-January/040985.html

-------------------------------------------------------------

About the "pip install" please use 3.8 as your base
and use "python3.8 -m pip .." to avoid misalignment
between python and pip

I plan to convert the test packages to stable

https://cygwin.com/packages/summary/python38.html

by this weekend or next one.
There will be surely some fallout :-(

After the switch or if you are already using the test packages,
if you need to switch between the several python/python3
possibilities, use "alternatives --config ...."

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

$ 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.

If you (or others) need other clarification, let me know
on this mailing list and I will try to clarify the matter.

Regards
Marco Atzeri

Cygwin Python maintainer

Re: Python packaging policy?

[Hamish McIntyre-Bhatty]

[-- Attachment #1.1.1: Type: text/plain, Size: 4235 bytes --]

On 20/01/2021 05:02, Marco Atzeri via Cygwin wrote:
> On 20.01.2021 00:02, Oleksandr Gavenko via Cygwin wrote:
>> I figured it out myself that I have to avoid "python3-*" packages and
>> instead
>> to work with "python36-*" or "python38-*" as "python3-*" packages are
>> marked
>> as "category: _obsolete" in setup.bz2.
>>
>> Are there any docs that describes policy for python packages in Cygwin?
>>
>> I had experience with
>> https://www.debian.org/doc/packaging-manuals/python-policy/
>> That document had answers to the most questions.
>
> Hi Ole,
> unfortunately not.
> We have not the bandwith to publish official documents as Debian.
> As you can see, that document is signed by all the maintainers that
> are probably working with python packages.
> The current team in Cygwin is one, and I took over from the previous
> maintainer when he decided to retire from the project.
>
> I addition Cygwin is a rolling distro so we need to
> maintanin some compatibility with the past as we evolve.
>
>> I tried to search for similar information under:
>>
>> /usr/share/doc/
>> /usr/share/doc/Cygwin
>>
>> and in
>>
>> git://cygwin.com/git/cygwin-htdocs.git
>>
>> and haven't succeeded.
>>
>> I'm interested in a package naming/versioning schema, a migration
>> path across
>> Python releases and the way of "pip install" to live in harmony with
>> Cygwin.
>>
>> I don't insist on anything particular but some "official" generic
>> guide how to
>> cook Python in Cygwin would be helpful.
>
> As you can seen from the several python announcements on the
> "cygwin-announce" mailing list
>
> https://sourceware.org/pipermail/cygwin-announce/
>
> ------------------------------------------------------------
> starting from April/June 2020 the work in progress is:
>
> -) update python-2.7, python-3.6, 3.7 and 3.8 at last versions
>
> python-2.7 is officially dead (EOL) upstream so only minor
> maintance is performed to "python27-*" packages
>
> python-3.5 is not updated anymore and will be removed in the future.
>
> -) move the meta-package python3 to pull python 3.8 instead of 3.6
>
> The retiring of python 3.6 is not too far, and some subpackages
> do not build anymore with it asking for at least 3.7.
>
> -) upload the "python38-*" for the majority of the subpackages
> most has been already done.
>
> Currently there are 158 / 159 / 122 packages for python 3.6/3.7/3.8
> and most of the difference is in obsoletes packages.
>
> -) work for python 3.9 will start after the rollout of 3.8 is completed.
> Probably a summer vacation excercise :-)
>
> -) check the packages still using python 2 and move the major ones to
> 3.8 (possibly)
>
> https://sourceware.org/pipermail/cygwin-apps/2021-January/040985.html
>
> -------------------------------------------------------------
>
> About the "pip install" please use 3.8 as your base
> and use "python3.8 -m pip .." to avoid misalignment
> between python and pip
>
> I plan to convert the test packages to stable
>
> https://cygwin.com/packages/summary/python38.html
>
> by this weekend or next one.
> There will be surely some fallout :-(
>
> After the switch or if you are already using the test packages,
> if you need to switch between the several python/python3
> possibilities, use "alternatives --config ...."
>
> $ alternatives --display python
> python - status is auto.
>  link currently points to /usr/bin/python3.8
> /usr/bin/python3.7 - priority 37
> /usr/bin/python2.7 - priority 27
> /usr/bin/python3.6 - priority 36
> /usr/bin/python3.8 - priority 38
> Current `best' version is /usr/bin/python3.8.
>
> $ 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.
>
> If you (or others) need other clarification, let me know
> on this mailing list and I will try to clarify the matter.
>
> Regards
> Marco Atzeri
>
> Cygwin Python maintainer

Is python3-* still okay for source package names, eg python3-wx that I
maintain?

Hamish


[-- Attachment #1.1.2: 0x87B761FE07F548D6.asc --]
[-- Type: application/pgp-keys, Size: 3235 bytes --]

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: Python packaging policy?

[Marco Atzeri]

On 20.01.2021 11:26, Hamish McIntyre-Bhatty via Cygwin wrote:
> On 20/01/2021 05:02, Marco Atzeri via Cygwin wrote:
>> On 20.01.2021 00:02, Oleksandr Gavenko via Cygwin wrote:

>>
>> About the "pip install" please use 3.8 as your base
>> and use "python3.8 -m pip .." to avoid misalignment
>> between python and pip
>>

> 
> Is python3-* still okay for source package names, eg python3-wx that I
> maintain?
> 
> Hamish
> 

I see no problem if you are just delivering only one python 3.X interface,
that usually is typical of providing a main program with a python
interface

your python3-wx, mine postgresql-plpython and the recent
python3-cv2 all fall in this case.

The scheme python 36 / 37 /38 is more for python purely packages

Regards
Marco