Many thanks for a helping hand!
Carsten Schoenert <
c.schoenert@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
--=-=-Content-Type: application/pgp-signature; name="signature.asc"
-----BEGIN PGP SIGNATURE-----
iIoEARYIADIWIQSjzJyHC50xCrrUzy9RcisI/kdFogUCZ21B+BQcc2ltb25Aam9z ZWZzc29uLm9yZwAKCRBRcisI/kdFoqvKAQCVv/IQ6erxc99K76nuL2KhCw+qkxeD 1Bu8fRvYTrCjxQEAmR6GRTYAHkF4dQ2cpxIci7TvLHEOOPVWGnZDrWaFBQkux
-----END PGP SIGNATURE-----
--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)