Path: csiph.com!tncsrv06.tnetconsulting.net!newsfeed.endofthelinebbs.com!news.corradoroberto.it!gothmog.csi.it!bofh.it!news.nic.it!robomod From: Simon Josefsson Newsgroups: linux.debian.maint.python Subject: Re: Bug#1091197: ITP: python-genson -- user-friendly JSON Schema generator Date: Thu, 26 Dec 2024 12:50:01 +0100 Message-ID: References: X-Original-To: Carsten Schoenert X-Mailbox-Line: From debian-python-request@lists.debian.org Thu Dec 26 11:46:07 2024 Old-Return-Path: X-Amavis-Spam-Status: No, score=-14.4 tagged_above=-10000 required=5.3 tests=[BAYES_00=-2, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FOURLA=0.1, LDO_WHITELIST=-5, PGPSIGNATURE=-5, RCVD_IN_DNSWL_MED=-2.3] autolearn=ham autolearn_force=no X-Policyd-Weight: using cached result; rate:hard: -4.6 Openpgp: id=B1D2BD1375BECB784CF4F8C4D73CF638C53C06BE; url=https://josefsson.org/key-20190320.txt X-Hashcash: 1:23:241226:debian-python@lists.debian.org::bNAPoiFS9nDpllzP:0dwr X-Hashcash: 1:23:241226:c.schoenert@t-online.de::okeAmJLc2db+BMkq:V3Wj User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.1 (gnu/linux) MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha256; protocol="application/pgp-signature" X-Mailing-List: archive/latest/22727 List-ID: List-URL: List-Archive: https://lists.debian.org/msgid-search/87frmawttz.fsf@kaka.sjd.se Approved: robomod@news.nic.it Lines: 168 Organization: linux.* mail to news gateway Sender: robomod@news.nic.it X-Original-Cc: debian-python@lists.debian.org X-Original-Date: Thu, 26 Dec 2024 12:46:00 +0100 X-Original-Message-ID: <87frmawttz.fsf@kaka.sjd.se> X-Original-References: <87jzbqsjq4.fsf__16847.3339335591$1734954690$gmane$org@kaka.sjd.se> <87o70zwauh.fsf@kaka.sjd.se> Xref: csiph.com linux.debian.maint.python:16633 --=-=-= Content-Type: text/plain Content-Transfer-Encoding: quoted-printable Many thanks for a helping hand! Carsten Schoenert writes: > Hello Simon, > > Am 26.12.24 um 02:23 schrieb Simon Josefsson: >> Hi. I'm struggling with packaging for this package: >> https://salsa.debian.org/python-team/packages/python-genson > > ... >> Why doesn't pybuild do the right thing by default? > > on which base pybuild could make the right decision? pybuild is doing > what it need and should do. > > The missing installation of the subfolder looks to me like an upstream > issue. > If the folder is needed for later usage it needs to get installed by > setuptools. Yes I suspected this may be an upstream issue, but I'm not familiar enough with python build systems to understand how to debug or have confidence in a upstream bug report. I tried to channel this forward: https://github.com/wolverdude/GenSON/issues/80 >> +execute_before_dh_auto_test: >> + cp -rv genson/schema .pybuild/cpython3_3.12/build/genson/ >> + cp -rv genson/schema .pybuild/cpython3_3.13/build/genson/ > > You can simplify this all by using the variable PYBUILD_BEFORE_TEST Which is not documented in pybuild(1) but now I found time to read https://wiki.debian.org/Python/Pybuild >> +export PYBUILD_BEFORE_TEST =3D cp -rv {dir}/genson/schema {build_dir}/$= (PYBUILD_NAME) Yay thank you! This works and is cleaner than my hack. All is not perfect, now autopkgtest fail with a different error. The strange thing is that this didn't happen in my 'hack' branch which ought to be fairly similar, except for maybe PYTHON_BUILD_NAME and the packaging merge. The autopkgtest was successful there. Ideas? https://salsa.debian.org/python-team/packages/python-genson/-/jobs/6820031 ___________________ ERROR collecting test/test_add_multi.py _______________= _____ ImportError while importing test module '/tmp/autopkgtest-lxc.394h6eqm/down= tmp/autopkgtest_tmp/build/test/test_add_multi.py'. Hint: make sure your test modules/packages have valid Python names. Traceback: /usr/lib/python3.13/importlib/__init__.py:88: in import_module return _bootstrap._gcd_import(name[level:], package, level) test/test_add_multi.py:1: in from . import base test/base.py:4: in from genson import SchemaNode, SchemaBuilder E ImportError: cannot import name 'SchemaNode' from 'genson' (/tmp/autopk= gtest-lxc.394h6eqm/downtmp/autopkgtest_tmp/build/genson/__init__.py) > And I personally would introduce another small package with just the > binary genson. To mee it's totally fine it's serverd by the package=20 > python3-genson. > It's done very often within other Python binary packages. Done! In the Go team the preference is the reverse, I believe, but I suppose the key difference for Python is that /usr/bin binaries end up being Architecture:any for Go programs but for Python they are still Architecture:all so there is no duplication of /usr/lib Python code for all the architectures which there would be for /usr/lib Go code if library+program are put in the same Debian binary package. I hadn't realized this difference can influence the packaging style so much. This decision makes lintian unhappy: X: python3-genson: application-in-library-section python [usr/bin/genson] N:=20 N: This package contains a binary in $PATH but is in a section just thoug= ht N: for libraries. It likely should be in another section like e.g. utils, N: text, devel, misc, etc., but not in e.g. perl, ruby or python. N:=20=20=20 N: People tend to skip these package sections when looking for applicatio= ns N: in the package list and hence wouldn't notice this package. N:=20=20=20 N: In case the program in $PATH is only a helper tool and the package is N: primarily a library, please add a Lintian override for this tag. N:=20 N: Visibility: info N: Show-Always: no N: Check: application-not-library N: This tag is experimental. It also makes deciding the section harder for the resulting combined tool+library package: X: python3-genson: library-package-name-for-application [usr/bin/genson] N:=20 N: This package contains a program in $PATH but is named like a library. = E.g. N: instead of libfoo-bar-perl it should be named just foo-bar. N:=20=20=20 N: People tend to skip library-like named packages when looking for N: applications in the package list and hence wouldn't notice this packag= e. N: See the reference for some (not perl-specific) reasoning. N:=20=20=20 N: In case the program in $PATH is only a helper tool and the package is N: primarily a library, please add a Lintian override for this tag. N:=20 N: Please refer to N: https://perl-team.pages.debian.net/policy.html#Package_Naming_Policy f= or N: details. N:=20 N: Visibility: info N: Show-Always: no N: Check: application-not-library N: This tag is experimental. I don't think 'genson' is a helper tool since it is generally useful for developers, so Section:devel felt appropriate but that triggers another lintian warning: I: python3-genson: wrong-section-according-to-package-name devel =3D> python N:=20 N: This package has a name suggesting that it belongs to a section other = than N: the one it is currently categorized in. N:=20 N: Visibility: info N: Show-Always: no N: Check: fields/section Is the pattern to silence such lintian complaints, or just ignore them in the Python team? > And if you define and use own variables in the file d/rules please > speaking namings. B and M are hard to read and for me using one=20 > character variable name is a bad habit. > > I would drop them completely, they are used just one time! Done. /Simon --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iIoEARYIADIWIQSjzJyHC50xCrrUzy9RcisI/kdFogUCZ21B+BQcc2ltb25Aam9z ZWZzc29uLm9yZwAKCRBRcisI/kdFoqvKAQCVv/IQ6erxc99K76nuL2KhCw+qkxeD 1Bu8fRvYTrCjxQEAmR6GRTYAHkF4dQ2cpxIci7TvLHEOOPVWGnZDrWaFBQk= =0fux -----END PGP SIGNATURE----- --=-=-=--