Why are distribution packagers obtuse about naming library packages python3-dostuff instead of libdostuff? If there's already a libdostuff, why not either (a) call it package libdostuff-ng, if it's actually a next-gen improvemnet, or (b) libdostuff-py, if it's simply an independent implementation?
How this helps anyone outside maybe ego deficient python language developers, and them not much, I can't guess.

I mean, nobody at netlib's asking for their software to be called fortran-lapack. I hope. And if they are, don't take them seriously.
#python #minirant #packaging

@http

There are a lot of #tools and #libraries - in #Python and other languages - that are basically #wrappers around #compiled libraries written in C, C++, or other compiled languages. In general, installing the Python package from a repository declares the binary library package as a #dependency.

A name collision between the Python package and the underlying C library would be problematic. You could argue that a Python library that exposes the functionality of `libfrobnicate`, which is part of the `frobnicate` package, shouldn't itself be called `frobnicate` but something totally different - but people go searching for "Python for Frobnicate" so it's a natural enough name. And therefore the repository maintainers have to make it `python-frobnicate` etc.