Yuri wrote:
Not every application-type package provides entry point(s) installed to ${BINDIR}. Further, Python package metadata doesn't care about any such distinction, as dependencies are checked for presence within the same distribution (same ${PYTHON_SITELIBDIR}). A further check can happen with importing the "application", which again, has to be present in the same distribution.On 2/15/24 22:48, Charlie Li wrote:This distinction does not practically exist; any Python package, even if primarily a program, can be specified and imported as a library in another as a dependency. See meson, which had to grow flavours when meson-python came about.This isn't true.If the program has one main function and several helper application-specific submodules - none of them can be used by any other software as dependency because everything is application-specific.
If the package has the description "Command line utility to xx" - this likely means that this is just a command line application and nothing more, and it shouldn't have the "py-" prefix.Still have to account for cases where such ports may be built and used against a non-default Python distribution. These cases are valid, especially when a Python package does not support anything but at least the latest Python version in our tree, but ${DEFAULT_VERSIONS} is not said Python version. While the cluster builders don't bother unless USE_PYTHON=allflavors is specified, those who build their own ports can set BUILD_ALL_PYTHON_FLAVORS. PKGNAME clashes happen without some kind of disambiguation.
-- Charlie Li ...nope, still don't have an exit line.
OpenPGP_signature.asc
Description: OpenPGP digital signature
