Hi again,

I would appreciate packaging review of 'betterproto':

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

Some questions/concerns:

- The dh_auto_test call fail, but debian/rules mask this error so the
build completes. Does anyone understand the error message? Is
'pydantic' too old in Debian? Help appreciated on this one.

https://salsa.debian.org/python-team/packages/python-betterproto/-/jobs/6792723#L1283

dh_auto_test
I: pybuild base:311: cd /build/python-betterproto-2.0.0b7/.pybuild/cpython3_3.13/build; python3.13 -m unittest discover -v
betterproto.lib.pydantic.google.protobuf.compiler (unittest.loader._FailedTest.betterproto.lib.pydantic.google.protobuf.compiler) ... ERROR
======================================================================
ERROR: betterproto.lib.pydantic.google.protobuf.compiler (unittest.loader._FailedTest.betterproto.lib.pydantic.google.protobuf.compiler)
---------------------------------------------------------------------- ImportError: Failed to import test module: betterproto.lib.pydantic.google.protobuf.compiler
Traceback (most recent call last):
File "/usr/lib/python3.13/unittest/loader.py", line 429, in _find_test_path
package = self._get_module_from_name(name)
File "/usr/lib/python3.13/unittest/loader.py", line 339, in _get_module_from_name
__import__(name)
~~~~~~~~~~^^^^^^
File "/build/python-betterproto-2.0.0b7/.pybuild/cpython3_3.13/build/betterproto/lib/pydantic/google/protobuf/compiler/__init__.py", line 208, in <module>
CodeGeneratorRequest.__pydantic_model__.update_forward_refs() # type: ignore
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
AttributeError: type object 'CodeGeneratorRequest' has no attribute '__pydantic_model__'. Did you mean: '__pydantic_config__'?
----------------------------------------------------------------------
Ran 1 test in 0.000s
FAILED (errors=1)

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

- Naming - right now it uses this style:

Source: python-betterproto
Package: python3-betterproto
Package: protoc-betterproto

Does that make sense? Similar to 'grpc', maybe this should be
'python-betterproto-protoc' instead? Or 'protoc-python-betterproto?
Or 'protoc-betterproto-python'?

- This uses tarballs from pypi.debian.net, which isn't identical to
upstream's GitHub git archive. Just like for 'grpc' it seems tests/
is missing. Maybe this is a common issue with PyPI tarballs? Is an
upstream request appropriate here?

- autopkgtest/piuparts fails because of the python-grpclib dependency.
I added a custom apt repository to debian/salsa-ci.yml however I don't
know how to make autopkgtest/piuparts pick that up. This will go away
once python-grpclib is in Debian.

- There is an X lintian complaint - is this common? Isn't a simpler fix
to chmod -x the file?

X: python3-betterproto: executable-in-usr-lib [usr/lib/python3/dist-packages/betterproto/plugin/main.py]
N:
N: The package ships an executable file in /usr/lib.
N:
N: Please move the file to /usr/libexec.
N:
N: With policy revision 4.1.5, Debian adopted the Filesystem Hierarchy
N: Specification (FHS) version 3.0.
N:
N: The FHS 3.0 describes /usr/libexec. Please use that location for
N: executables.
N:
N: Please refer to File System Structure (Section 9.1.1) in the Debian Policy N: Manual, filesystem-hierarchy,
N: https://refspecs.linuxfoundation.org/FHS_3.0/fhs/ch04s07.html, and
N: Bug#954149 for details.
N:
N: Visibility: pedantic
N: Show-Always: no
N: Check: files/permissions/usr-lib
N: This tag is experimental.
N:
N: Screen: emacs/elpa/scripts
N: Advocates: "David Bremner" <[email protected]>
N: Reason: The emacsen-common package places installation and removal
N: scripts, which for ELPA packages are executable, in the folder N: /usr/lib/emacsen-common/packages.
N:
N: About four hundred installation packages are affected. All of
N: them declare emacsen-common as an installation prerequisite.
N:
N: Read more in Bug#974175 and Bug#954149.
N:
N: Screen: web/cgi/scripts
N: Advocates: "Andrius Merkys" <[email protected]>
N: Reason: The folder /usr/lib/cgi-bin/ is designated for scripts in the
N: Common Gateway Interface (CGI). They require the executable bit N: so the server can run them.
N:
N: Read more in
N: https://en.wikipedia.org/wiki/Common_Gateway_Interface,
N: https://datatracker.ietf.org/doc/html/rfc3875.html, and
N: Bug#1003941.

- Others?

/Simon

Simon Josefsson <[email protected]> writes:

Package: wnpp
Severity: wishlist
Owner: Simon Josefsson <[email protected]>
X-Debbugs-Cc: [email protected], [email protected]

* Package name : python-betterproto
Version : 2.0.0b7
Upstream Author : Daniel G. Taylor
* URL : https://github.com/danielgtaylor/python-betterproto
* License : MIT
Programming Lang: Python
Description : better Protobuf / gRPC generator & library

This project aims to provide an improved experience when using
Protobuf / gRPC in a modern Python environment by making use of modern
language features and generating readable, understandable, idiomatic
Python code. It will not support legacy features or environments
(e.g. Protobuf 2). The following are supported:

- Protobuf 3 & gRPC code generation
- Both binary & JSON serialization is built-in
- Python 3.6+ making use of:
- Enums
- Dataclasses
- async/await
- Timezone-aware datetime and timedelta objects
- Relative imports
- Mypy type checking

I plan to maintain this package as part of the Python team:

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

Work in progress will hopefully be found here:

https://salsa.debian.org/jas/python-betterproto

/Simon

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

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

iIoEARYIADIWIQSjzJyHC50xCrrUzy9RcisI/kdFogUCZ2XzPBQcc2ltb25Aam9z ZWZzc29uLm9yZwAKCRBRcisI/kdFoizlAQCLaNAUX9iGcPH7laIeNnCaBJuWicxm Csx+Alf9TKJO3QEAuQ1+SYw4qbQ2l918jIgJ3m54rsrP2kk3U5on1u6rPg8=nBju
-----END PGP SIGNATURE-----

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