On Wed, Jul 12, 2023 at 11:16:28AM +0100, Simon McVittie wrote: > 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. Oh yeah, I just tried to say that packaging them separately is not the only option and probably not even the main option.
> 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. There is a popular concern about having binary packages that consist of a 1 kB file + changelog + copyright. It also somewhat complicates packaging, unfortunately. > 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). Yup.
