Re: python conflict question

[Greg Troxel <gdt%lexort.com@localhost>]

"J. Lewis Muir" <jlmuir%imca-cat.org@localhost> writes:

> 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.

You are basically right about this being awkward.  Keep in mind that the
root cause is poor inter-version compatibilty in Python; if we could
just use any python version for any program, we would probably only have
one (like perl).

Given that we are talking about mitigating awkwardness, it's a
non-obvious call what the approach is for the least total problems.
Adding another 100 metapackages foo to wrap py-foo seems like it might
be more trouble than it is worth.  I find that that I have to "ls -l
*/*foo*" to find the foo package anyway, so the py- prefix doesn't
bother me much.

Perhaps if pkgin said when "pkgin in certbot" is invoked:
  There is no "certbot"; did you mean "py-certbot"?

that would help a lot.