Re: how to properly split up into python3-foo and foo-util package?
On Wed, 12 Jul 2023 at 11:19:07 +0200, Andrey Rakhmatullin wrote:
> I don't think "usr/bin stuff should likely go
> in the other". Many Python module packages ship executables, especially
> now that you no longer have Python 2 subpackages.
I would personally say that if the executables are significant, and
particularly if we expect that users will use them without knowing or
caring whether they are implemented in Python, then they should be in
a package with a name and Section that make it look like an executable
program and not a Python library: if nothing else, that will make them
a lot more discoverable. So I think Christoph is probably correct to be
thinking about shipping them as foo-util or similar.
If nothing else, making executables part of the interface of the
python3-foo package is going to come back to bite us when Python 4 happens
(hopefully not soon, but if there have been 3 major versions then there
will probably be a 4th eventually).
If the Python library is considered to be a public API, then it should
be in a python3-foo library. src:binwalk and src:tap.py are examples
of separating out executable + library like this.
If the Python library is considered to be a private implementation detail
of the executables, then it doesn't need to be packaged separately
(for example bmap-tools, dput, meson and offlineimap all contain
private Python libraries that are not a stable API), and ideally it
would be in a location that is not on the default import search path,
like /usr/share/foo or /usr/lib/foo (dput and offlineimap do this,
although bmap-tools and meson don't).
smcv
Reply to: