Re: "py-" prefix shouldn't be needed for Python-based ports that are programs, not libraries

Yuri wrote:
> 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.
> 
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.
> 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.