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" <bremner@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" <merkys@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 <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-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
>
Attachment:
signature.asc
Description: PGP signature