Re: python conflict question

["J. Lewis Muir" <jlmuir%imca-cat.org@localhost>]

On 06/16, Thomas Klausner wrote:
> On Tue, Jun 16, 2020 at 01:29:13PM +0200, Nikita Gillmann wrote:
> > I think I was a bit too brief. I meant our ${PYVER}-binary naming, not
> > the package name.
> 
> I think I know what you mean:
> 
> For py*-packages, i.e. the ones that are built by default for multiple
> python versions, we usually rename bin/foo to bin/foo-${PYVERSSUFFIX},
> to avoid them conflicting and allowing parallel installation of
> multiple python versions of the same package/library.

Agreed.  I think that's a good approach: use a package name prefix of
"py*-" for Python libraries or for Python-specific packages (e.g., that
can be installed via pip).  That makes sense.  Ruby has a similar thing
with gems, and gems can provide libraries, binaries, or both.

> We usually do not do this for packages that are just written in python
> and do not provide a library that is used by other packages, see e.g.
> devel/meld.

Agreed again.  For a package that's providing a program, the package
name should definitely *not* begin with a short language (and version)
prefix (e.g., "py*-") because that's an implementation detail.  The
program could be rewritten in a different language in the future, and
its name might very well remain the same.

Things get confusing to me, though, when I see packages like
devel/py-mercurial.  This came up in a thread that mentioned that
the Certbot package was actually at security/py-certbot, not
security/certbot:

  https://mail-index.netbsd.org/netbsd-users/2019/10/22/msg023517.html

In that thread, I learned that Mercurial had the same problem
(devel/py-mercurial), but that the problem was solved by making it
also available at devel/mercurial as a meta package (that included
devel/py-mercurial) to make it available at a name that people would
expect.

Unfortunately, Certbot does not have a meta package at security/certbot;
it just has security/py-certbot.  As a user, I would expect to find
it at security/certbot for the same reason that Mercurial has a meta
package at devel/mercurial: it's what people expect.  When I navigate to
the Certbot website

  https://certbot.eff.org/

it's clearly presented as a program "for automatically using Let's
Encrypt certificates on manually-administrated websites to enable
HTTPS."  The fact that it's written in Python is inconsequential from a
user perspective.  IMO, it would be good to have a security/certbot meta
package.  It is nice that security/py-certbot installs bin/certbot via
the alternatives mechanism, but it's still not easy to find the package
if you don't know to allow for the "py*-" name prefix.

It's also awkward from a user perspective when installing binary
packages: you can't do "pkgin install certbot"; instead you have to do
"pkgin install py38-certbot" (replacing 38 with whatever version of
Python you want it to use that's available as a binary package).  That's
just weird from a user perspective: I just want the Certbot program, I
don't care what version of Python it uses.

Certbot is just an example.  IMO, it would be good for any program
like this to have a meta package like Mercurial does if it must have
the short language prefix name.  I understand the rationale that
devel/py-mercurial has other packages that use it.  That's fine.
And it makes it available at the name you'd expect by having the
devel/mercurial meta package.  It's just that for any program like this,
I think the user is expecting to find it at a name that does not begin
with the short language prefix.

Lewis