Many thanks for a helping hand! Carsten Schoenert <c.schoen...@t-online.de> 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 = 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/downtmp/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 <module> from . import base test/base.py:4: in <module> from genson import SchemaNode, SchemaBuilder E ImportError: cannot import name 'SchemaNode' from 'genson' (/tmp/autopkgtest-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 > 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: N: This package contains a binary in $PATH but is in a section just thought 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: N: People tend to skip these package sections when looking for applications N: in the package list and hence wouldn't notice this package. N: 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: 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: 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: N: People tend to skip library-like named packages when looking for N: applications in the package list and hence wouldn't notice this package. N: See the reference for some (not perl-specific) reasoning. N: 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: N: Please refer to N: https://perl-team.pages.debian.net/policy.html#Package_Naming_Policy for N: details. N: 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 => python N: N: This package has a name suggesting that it belongs to a section other than N: the one it is currently categorized in. N: 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 > character variable name is a bad habit. > > I would drop them completely, they are used just one time! Done. /Simon
signature.asc
Description: PGP signature
