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
Attachment:
signature.asc
Description: PGP signature