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" <brem...@debian.org> 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" <mer...@debian.org> 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 <si...@josefsson.org> writes: > Package: wnpp > Severity: wishlist > Owner: Simon Josefsson <si...@josefsson.org> > X-Debbugs-Cc: debian-de...@lists.debian.org, debian-python@lists.debian.org > > * 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 >
signature.asc
Description: PGP signature
