Hi Python Team,

I have prepared packaging of 'grpclib' and I'm new to Python packaging,
so I would appreciate open minded review of how this is packaged:

https://salsa.debian.org/python-team/packages/python-grpclib

Please bring up stylistic concerns, for me to learn. I plan to upload
this to NEW shortly.

Some of the questions/concerns I have are:

- Do the /usr/bin binaries have to go in a separate package, or could
they be in the python3-grpclib binary package? I believe they are
developer-only tools of limited applicability.

- Naming - right now it uses this style:

Source: python-grpclib
Package: python3-grpclib
Package: protoc-grpclib

Does that make sense? Upstream calls itself 'grpclib' but using
'python-grpclib' in Debian seems nicer. I see there is a
'rustc-protoc' in the archive, maybe this should be
'python-grpclib-protoc' instead? Or 'protoc-python-grpclib'? Or
'protoc-grpclib-python'?

- This uses tarballs from pypi.debian.net, which isn't identical to
upstream's GitHub git archive. It seems tests/ are missing. I've
approached upstream about including them in the PyPI upload --
https://github.com/vmagamedov/grpclib/issues/200 -- but I'm not sure
what the best practices are here. Is using the pypi.debian.net
tarball recommended? Or do people package the github.com tarball
instead? Or directly from git? What do we do when some stuff is
missing from the PyPI archive?

- Man pages are missing - the tools doesn't respond to -h or --help, I
suppose this is an upstream request, or are there any other ideas on
that?

- Others?

/Simon

Simon Josefsson <simon@josefsson.org> writes:

Package: wnpp
Severity: wishlist
Owner: Simon Josefsson <simon@josefsson.org>
X-Debbugs-Cc: debian-devel@lists.debian.org, debian-python@lists.debian.org

* Package name : python-grpclib
Version : 2.0.0b7
Upstream Author : Vladimir Magamedov, et al
* URL : https://github.com/vmagamedov/grpclib
* License : BSD-3-Clause
Programming Lang: Python
Description : Pure-Python gRPC implementation for asyncio

This is a Pure-Python gRPC implementation for asyncio.

https://salsa.debian.org/python-team/packages/python-grpclib

/Simon

-----BEGIN PGP SIGNATURE-----

iIoEARYIADIWIQSjzJyHC50xCrrUzy9RcisI/kdFogUCZ2XqaxQcc2ltb25Aam9z ZWZzc29uLm9yZwAKCRBRcisI/kdForwLAP0fzvBewT6WCxb1ZMOBNjgymB/zc8xf Xxxx9Yw4SyBTWwEAkEDbWCy8aaxdbJSuTXy0AGAIvJhGM/YKkfONz5k/FgI=
=67mO
-----END PGP SIGNATURE-----

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Copy: simon@josefsson.org (Simon Josefsson)

Simon,

On Friday, December 20, 2024 3:06:35 PM MST Simon Josefsson wrote:

Hi Python Team,

I have prepared packaging of 'grpclib' and I'm new to Python packaging,
so I would appreciate open minded review of how this is packaged:

https://salsa.debian.org/python-team/packages/python-grpclib

Please bring up stylistic concerns, for me to learn. I plan to upload
this to NEW shortly.

Some of the questions/concerns I have are:

- Do the /usr/bin binaries have to go in a separate package, or could
they be in the python3-grpclib binary package? I believe they are
developer-only tools of limited applicability.

- Naming - right now it uses this style:

Source: python-grpclib
Package: python3-grpclib
Package: protoc-grpclib

Does that make sense? Upstream calls itself 'grpclib' but using
'python-grpclib' in Debian seems nicer. I see there is a
'rustc-protoc' in the archive, maybe this should be
'python-grpclib-protoc' instead? Or 'protoc-python-grpclib'? Or
'protoc-grpclib-python'?

- This uses tarballs from pypi.debian.net, which isn't identical to
upstream's GitHub git archive. It seems tests/ are missing. I've
approached upstream about including them in the PyPI upload --
https://github.com/vmagamedov/grpclib/issues/200 -- but I'm not sure
what the best practices are here. Is using the pypi.debian.net
tarball recommended? Or do people package the github.com tarball
instead? Or directly from git? What do we do when some stuff is
missing from the PyPI archive?

I am not experienced enough with Python packaging to respond to your other questions, but I do know that many Python packages pull from github or gitlab when thinks like tests are missing from PyPI, so you should feel free to do so when needed.

- Man pages are missing - the tools doesn't respond to -h or --help, I
suppose this is an upstream request, or are there any other ideas on
that?

- Others?

/Simon

Simon Josefsson <simon@josefsson.org> writes:

Package: wnpp
Severity: wishlist
Owner: Simon Josefsson <simon@josefsson.org>
X-Debbugs-Cc: debian-devel@lists.debian.org, debian-

python@lists.debian.org

* Package name : python-grpclib

Version : 2.0.0b7
Upstream Author : Vladimir Magamedov, et al

* URL : https://github.com/vmagamedov/grpclib
* License : BSD-3-Clause

Programming Lang: Python
Description : Pure-Python gRPC implementation for asyncio

This is a Pure-Python gRPC implementation for asyncio.

https://salsa.debian.org/python-team/packages/python-grpclib

/Simon

--
Soren Stoutner
soren@debian.org
-----BEGIN PGP SIGNATURE-----

iQIzBAABCgAdFiEEJKVN2yNUZnlcqOI+wufLJ66wtgMFAmdm/TEACgkQwufLJ66w tgOOcA//WLBg7C3FJ5imF2W6JVUExSkCRVb1JmueYDuU6j69gyToj6vsiGgsUw1U 71rHwqjJV/nfGJFZFQSMJWOuVES9f9QSK66kJ0iqyzNsiKr/HgjMGQgncsNhm+cs S8E/gKMoc3nCzbkFDf4H1Ztmc+Z/Vp8c88af4RrWLjiWSTS1eIupwcLjHK8ggJIA Yp83k6sme3I9p4YzxnDL6n4TGblMS9tHC9fWkc1rnXsBDkBl8m+njW3Ph2aTmnxi 8HGIwiGI1mplzS9KS0riu8DRWnHFz5B24l1JpgxATORzRPBee9KTuFx+oKP6TeMs IFffZqXcQQePOF/KM0FGb3um9WhvoY9hZYQNAQ9IPfO6O5ObVD632gR7QQrOG3kT m//eGw0y8i7/xFczveu1H9pHtUVCKHmWyX68YFvYtPzKknb+irZyf4uW2O2lud4b AZTVCE6wx2DaK5lxr3VuH/hTWSaUbQYltpEbfUqrK3kjbhf5yTNU7TUIAS4lrCqn iXhpobkLVWJjBvhYuXZfn7UPG8Dz3LvTszpgS6LV+7b3HoyuIWrhob5cNXUQYfFX vKBrOoxRccHQ6wCBFBQciO2BLTWe4Ja2DzxyoZXvjzoRNgcFRyfnQYHDWPK/XW3l 8fyvlukdD9iReIt+d4maCLSoaCsY/TiHhfpT2zRwWwFrVpgTa6U=
=m7q1
-----END PGP SIGNATURE-----

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Soren Stoutner <soren@debian.org> writes:

- This uses tarballs from pypi.debian.net, which isn't identical to
upstream's GitHub git archive. It seems tests/ are missing. I've
approached upstream about including them in the PyPI upload --
https://github.com/vmagamedov/grpclib/issues/200 -- but I'm not sure
what the best practices are here. Is using the pypi.debian.net
tarball recommended? Or do people package the github.com tarball
instead? Or directly from git? What do we do when some stuff is
missing from the PyPI archive?

I am not experienced enough with Python packaging to respond to your other questions, but I do know that many Python packages pull from github or gitlab
when thinks like tests are missing from PyPI, so you should feel free to do so
when needed.

Thanks for insight! This is good to know. I prefer to ask upstreams to include the relevant stuff into the PyPI tarball instead. However if it
turns out upstreams don't want to do that (or that doing so is against
PyPI best practices somehow) AND there is significant advantage in using upstream's github as the tarball source, then at least I know this isn't considered a big no-no for Debian packages.

So far I've only noticed that some self-tests and auxilliary files are
missing from the PyPI tarballs, and I don't consider that to be
important enough to deviate from using the pypi.debian.net sources yet.

/Simon

--=-=-Content-Type: application/pgp-signature; name="signature.asc"

-----BEGIN PGP SIGNATURE-----

iIoEARYIADIWIQSjzJyHC50xCrrUzy9RcisI/kdFogUCZ2hLDBQcc2ltb25Aam9z ZWZzc29uLm9yZwAKCRBRcisI/kdFol0fAPoDwhPZPNtSEQl2JILNslRx2EcF4uov kcW+VRVwPpC+qAD/eapYf8lnmJAumGhH0NwykE/KZBI/GzFWtDtw8XfNGAg=aOfn
-----END PGP SIGNATURE-----

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

I have uploaded python-grpclib to NEW. I settled for including the command-line tools even though they may be rarely used developer tools,
under the 'protoc-grpclib' name (I tried 'python-grpclib-protoc and 'python-protoc-grpclib' but then lintian complained about using python-* namespace). It still uses the PyPI tarball, it seems to work fine and
I've opened upstream reports about including self-tests and man pages.
I added Testsuite:autopkgtest-pkg-pybuild to be prepared for when
upstream adds self-tests.

/Simon

-----BEGIN PGP SIGNATURE-----

iIoEARYIADIWIQSjzJyHC50xCrrUzy9RcisI/kdFogUCZ2k0PRQcc2ltb25Aam9z ZWZzc29uLm9yZwAKCRBRcisI/kdFoqniAQCXHM8u3lEK9mP+nsLSK8XaFZxDI57D oKlQA8Kof4WH4gD/Z555Jb+14ILzpcwhUCIOEWchFXmd3+XbkeVEwQY4swI=
=oIuc
-----END PGP SIGNATURE-----

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Sun, Dec 22, 2024 at 06:23:24PM +0100, Simon Josefsson wrote:

So far I've only noticed that some self-tests and auxilliary files are missing from the PyPI tarballs, and I don't consider that to be
important enough to deviate from using the pypi.debian.net sources yet.

Hi Simon,

There is no Debian Python policy to use PyPI versus GitHub versions as
far as I am aware. However, the PyPI versions of packages frequently
do not include the test suites, as many developers regard those as
part of the development environment, not the release environment (and
having test suites included in all packages could cause significant
bloat). You are, of course, welcome to ask them to reconsider for
this package, but you may not have any success, and I wouldn't rely on
them agreeing to your request.

Whatever the outcome of your negotiations, the Debian Python team is
very keen on having autopkgtests for as many packages as possible:
doing so catches all sorts of bugs and can prevent your package from mysteriously breaking. So given that upstream have written a test
suite that you have easy access to (via GitHub), unless you have a
very strong reason *not* to include it in the Debian sources, you
really ought to do so. "It isn't included in the PyPI source tarball"
is not a strong reason. So it seems that you have a few choices:

(1) Use the GitHub sources in place of the PyPI sources.

(2) Use the GitHub sources, patched in those few places where the PyPI
version differs to match the PyPI version. (This can be done via debian/patches.)

(3) Use the PyPI sources and include the test suite from GitHub; this
could be done via the dpkg-source components mechanism, for example.
It would complicate the packaging a bit, and make upgrading harder
work, but it would certainly be feasible.

(4) Decide on principle that you're going to stick with the PyPI
version come what may, and as upstream haven't included a test suite
in that version, the Debian package won't either.


I am sure I'm not alone on the Debian Python Team in strongly
discouraging you from following option (4). My personal preference
would be (1) or (2), depending on how significantly different the
GitHub and PyPI versions are. (And this does also assume that the
developers have tagged their Git repository with appropriate tags.)

Best wishes,

Julian

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Julian Gilbey <julian@d-and-j.net> writes:

On Sun, Dec 22, 2024 at 06:23:24PM +0100, Simon Josefsson wrote:

So far I've only noticed that some self-tests and auxilliary files are
missing from the PyPI tarballs, and I don't consider that to be
important enough to deviate from using the pypi.debian.net sources yet.

Hi Simon,

There is no Debian Python policy to use PyPI versus GitHub versions as
far as I am aware. However, the PyPI versions of packages frequently
do not include the test suites, as many developers regard those as
part of the development environment, not the release environment (and
having test suites included in all packages could cause significant
bloat). You are, of course, welcome to ask them to reconsider for
this package, but you may not have any success, and I wouldn't rely on
them agreeing to your request.

Whatever the outcome of your negotiations, the Debian Python team is
very keen on having autopkgtests for as many packages as possible:
doing so catches all sorts of bugs and can prevent your package from mysteriously breaking. So given that upstream have written a test
suite that you have easy access to (via GitHub), unless you have a
very strong reason *not* to include it in the Debian sources, you
really ought to do so. "It isn't included in the PyPI source tarball"
is not a strong reason. So it seems that you have a few choices:

(1) Use the GitHub sources in place of the PyPI sources.

(2) Use the GitHub sources, patched in those few places where the PyPI version differs to match the PyPI version. (This can be done via debian/patches.)

(3) Use the PyPI sources and include the test suite from GitHub; this
could be done via the dpkg-source components mechanism, for example.
It would complicate the packaging a bit, and make upgrading harder
work, but it would certainly be feasible.

(4) Decide on principle that you're going to stick with the PyPI
version come what may, and as upstream haven't included a test suite
in that version, the Debian package won't either.

I am sure I'm not alone on the Debian Python Team in strongly
discouraging you from following option (4). My personal preference
would be (1) or (2), depending on how significantly different the
GitHub and PyPI versions are. (And this does also assume that the
developers have tagged their Git repository with appropriate tags.)

Thank you! I'm happy to adopt 1) but I didn't want to do that without
some +1 on doing so since

https://wiki.debian.org/Python/LibraryStyleGuide?action=show&redirect=Python%2FPackaging#debian.2Fwatch

says 'Thus, it is highly recommended that you update your existing
packages to the new debian/watch format described here'

and 'Since probably for most of our packages, the original tarball comes
from the Python Package Index (a.k.a. PyPI or the Cheeseshop)'

which give me the impression that using PyPI tarballs is generally
preferred, so it is hard for me as newbie to understand the preferences.

I do agree that self-tests are important, and I was surprised
maintainers don't include them in the PyPI tarballs. Maybe it is not
worth our time to open bug reports about changing the PyPI tarballs, and switching to the GitHub tarballs is fine.

Another question is about which version to package -- latest GitHub tag
or PyPI version? Have a look at this project:

https://pypi.org/project/sigstore-protobuf-specs/#history

I suppose I may run into whatever bug that prompted this yanking too...

/Simon

--=-=-Content-Type: application/pgp-signature; name="signature.asc"

-----BEGIN PGP SIGNATURE-----

iIoEARYIADIWIQSjzJyHC50xCrrUzy9RcisI/kdFogUCZ2nOABQcc2ltb25Aam9z ZWZzc29uLm9yZwAKCRBRcisI/kdFoiyPAQCQ9zEitNjPp4MWCGr7O5tN7qK7xQxp PMfOfwmi2QeohwD/cc1VxyBA8xc43poLUFZkhtkWBEoVJGUuIH7acDwKsAw=xJJE
-----END PGP SIGNATURE-----

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)