Hi,
On Fri, 7 Jun 2019 at 01:49, Ryan Schmidt wrote:
>
> Originally, all-lowercase port names were encouraged, because users often
> specify port names in all lowercase and there were a few bugs in MacPorts
> when the capitalization specified did not match the capitalization used in
> the port. But those bugs have been fixed for years so all-lowercase names
> should no longer be preferred, and using upstream capitalization probably
> makes sense.
For perl we consistently use lowercase for *every single perl module*,
and I need to say that I prefer that to a random capitalisation mess.
To avoid digging too far into exotic package, let's simply start with
MacPorts itself. The official name is CamelCase MacPorts. Yet our
official repository on GitHub is "macports" and "macports-ports",
rather than "MacPorts/MacPorts-Ports". Our usual argument, in
particular with GitHub repositories, is most often that we should
match the case of the github project. Can we – for a start – just
clarify how we would name the macports python module if one existed?
Would it be py-macports or py-MacPorts? Would a python module be
py-buildbot or py-Buildbot, given that you see the name written with
the capital letter all over the place? Add to that that I'm pretty
sure there are many modules that used a different capitalisation on
pypi than they do on GitHub. Which capitalisation would then be the
correct one?
I understand that the convention of keeping the capitalisation often
makes sense, but in the case of perl / python / ruby modules I would
stick with lowercase, in particular because it doesn't look as nice
after the artificial "py-" prefix that we always stick in front of it.
We can use some kind of
pypi.setup SomeCamelCase 0.1
to set up whatever needs to be done to point to uppercase names, but I
would find it at least a tiny bit annoying to read (and to some extent
type) camelcase.
Mojca
PS: And no, we didn't yet solve all of our fix with casing. The command
port info codeblocks +wxWidgets28
still doesn't work as expected. (There was also a wish to support dots
in variant names which never got implemented.)
