There is also the possibility of using Toolbx (formerly [Fedora] Toolbox), distrobox or a container, and the underlying container's package manager. The issue then ends up being about how ergonomic it is to manage a separate guest system (and have to drop into it anytime we wish to use a binary that is unavailable in the host).
I am not sure it is recommending more than it is commenting on the current state of developing public-facing APIs in Python.
The downstream users that import the package either have to ignore checking its exported types altogether, manually stub it, or have a subpar development experience to varying degrees.
This is something I saw the other day with some package that provided comprehensive stubs for an untyped library. The .pyi file was littered with comments about quirks from the numerous type checkers (five now).
I recently installed Fedora Kinoite [1] and I have been very pleasantly surprised by how stable and performant it is. I am afraid I cannot say the same for their new KDE Linux distribution [2] which in my opinion was a bit unpolished at the time. Both are immutable desktop distributions.
The good news, I guess, is Kinoite stands to benefit from KDE Linux development because it mostly depends on Flatpak to install programs which means all of the KDE ecosystem will eventually be available at Flathub [3] as first-class citizens with reasonable maturity.
Or become a major investor on a largely public funded project with commitments set to start at a delayed time in order to benefit from R&D before bearing financial burden. (See [1].)
Seems very promising but then you realize the LLM behind said agent was trained on public but otherwise copyright encumbered proprietary code available as improperly redistributed SDKs and DDKs, as well as source code leaks and friends.
In fact most Windows binaries have public debug symbols available which makes SRE not exactly a hurdle and an agent-driven SRE not exactly a tabula rasa reimplementation.
Nice although I think the ASCII comma feels wrong as part of a filename even if for purely aesthetic reasons.
If we want to stay within (lowercase) alphabetic Latin characters I think prefixing with the least common letters or bigrams that start a word (x, q, y, z, j) is best.
`y' for instance only autocompletes to `yes' and `ypdomainname' on my path.
Choosing a unique bigram is actually quite easy and a fun exercise.
And we can always use uppercase Latin letters since commands very rarely use never mind start with those.
Debian testing is about as stable as it gets while also being a rolling distribution. The promotion of package updates from unstable to testing does not take that long either depending on the severity. I would venture a guess that there is more to it.
And over Fedora/RHEL. If I had to guess, it could be that new entrants find it easier to submit changes to Arch Linux packages [1]. ChromeOS also steered away from Debian-based distributions, choosing a Gentoo base.