Open notramo opened 11 months ago
I don't know what I should do with this information.
Maybe add an alias to the binary, like moar-pager
?
Do you have any links to how the MoarVM people are dealing with this?
I should be able to follow their lead.
I don't have a good solution, but my thoughts right now are:
The most obvious solution would be to call the MoarVM binary moarvm
. Or maybe raku
/ rakuvm
. All of those renamings sound to me like they would make a lot of sense, and it would resolve the naming conflict.
Since you care about this, please open a ticket! Or even better, PRs. Or explain to me why this is a stupid idea :).
After that has been tried, I think this is a packaging issue. How did you install moar
? Maybe this should be brought up with the package maintainers?
This can't be the first time in history there's a naming clash. How did they resolve it previously?
Tagging with help-wanted.
If you're interested in this, please open a conversation with the MoarVM people to rename their binary and link to it from here as per my previous comment.
Why should they rename it? Their project is more established than this one.
@notramo, please read my previous comment on this: https://github.com/walles/moar/issues/143#issuecomment-1728842781
Kindly clarify which part(s) of it are unclear or wrong.
Also, after reading that, if you still expect some sort of action from my side, please clarify what your expectation would be.
The reason I tagged this with help-wanted was that I never got any response to my suggestion.
As the MoarVM had its first release in 2014, it is unlikely that they would change their default binary installation name or that nqp or rakudo would know to look for moarvm
. As @notramo said, it's been around for a while.
The suggestion made by @Techcable was to make it so that this could be installed as moar-pager
, which should be doable by optional edits to your install.sh
script and/or having a secondary installable name (cmd/moar-pager.go
so that go install gihub.com/walles/maor/cmd/moar-pager@latest
would work).
I plan on opening a PR for the moar
port in MacPorts that will suggest:
moar
to moar-pager
moar-pager
instead of moar
Otherwise, the port will need to be marked as having a conflict with moarvm
, because while more people might be interested in moar
the pager, the existence of $PAGER
makes it so that for most things, one doesn't have to think about the name of moar
.
As the MoarVM had its first release in 2014,
moar
's first release was in 2013: https://github.com/walles/moar/releases/tag/0.9
it is unlikely that they would change their default binary installation name
Kindly link to the conversation you had with the MoarVM maintainers about this.
Kindly link to the conversation you had with the MoarVM maintainers about this.
I neither use moar
nor MoarVM, and I do not plan on having such a conversation. I came to this discussion via the macports-users list where someone who does use Raku (and therefore MoarVM) and noticed that MacPorts is not properly blocking against this particular name conflict.
You asked for feedback, and I provided such. I also outlined what I am going to be proposing in the MacPorts Trac (regarding renaming the moar
port and binary to moar-pager
) and creating a PR on macports-ports (regarding adding a conflict marker until movement is made on the Trac ticket.
If you choose not to add alternative naming, that is your prerogative and I fully support your choice to do so. But the whole point of package managers is to either make it impossible to have a situation where binary name conflicts occur or to call them out so that you, as the upstream developer, don’t have to.
Will you be making MacPorts specific changes to riff
and ugrep
as well to not break their moar
integration for MacPorts users?
I don't understand from this thread how it was decided that the "more established" project (@notramo's words) should change?
Renaming MoarVM would be fairer because moar
has been around for longer, and renaming the MoarVM binary should affect fewer users since moar
is used by more people.
I don’t actually think that moar
is the "more established" project. The MoarVM is the latest iteration of several VMs used during the Perl 6 / Rakudo development cycles which I have followed off and on for going on twenty years. The oldest tag that I could find from the MoarVM was the 2014.1 release when they apparently moved development to GitHub. That does not mean that it was the first release, but perhaps the first "stable" release. I haven’t followed its development that closely, but as a language aficionado I have certainly followed it periodically.
On the other hand, the first I had heard of moar
, riff
, and urge
was yesterday, yesterday, and today (respectively). Not that my not hearing about a project is a sign of anything except that there are a lot of projects out there and it’s really hard to hear about most of them.
If the decision is made to rename the moar
binary is made (this is not up to me; there are port maintainers and there is a ticket open which proposes this), we can explore patches to riff
and ugrep
— although the general preference by most package maintainers is to have such patches applied upstream (that is, riff
and ugrep
could be modified to look for $PAGER
, moar
, moar-pager
, and less
) where possible.
When Google released go
, there were complaints about conflicting projects and binaries (including one other software development language, Go!).
Just personally, I would not use the Homebrew analytics data as anything serious, since most Go programs are also installable like go install GitHub.com/walles/moar@latest
(and how I install most Go programs, because I don't like Homebrew even as I use it) and it covers a large fraction of macOS users and a very small fraction of Linux users … and pretty much no one else.
Aside from what I have recommended for moar
in macports:trac#68491, I think it would be friendlier to your users who also happen to be users of NQP/Rakudo to offer an option of installing moar
as moar-pager
.
If I have time (doubtful right now), I am going to see if it is possible for MacPorts to declare that a variant does not conflict so that people who use both MoarVM
and moar
can install them side-by-side with sudo port install MoarVM moar+pager
and the moar
binary and manpage will be installed as moar-pager
, because getting a language ecosystem to move is far more trouble than changing a pager utility and other tools that can take advantage of it out of the box.
Thanks @halostatue, this provides a much more nuanced perspective than what's been presented so far in this thread.
Personally I had never heard of neither raku
nor nqp
before this thread started, and I thought that MoarVM and ScummVM were the same thing.
I want to do what you did @halostatue and provide background from my perspective.
I started moar
development in 2013. The first version was released in November.
Since 2013 I've been using moar
multiple times per day, and I'm now on my 11th year of moar
usage.
Using moar
both means typing moar somefile.txt
in the terminal and having my $PAGER
variable set so that git
, man
and others find and use moar
as their pager.
So @Techcable, your suggestion of renaming to "moar-pager" wouldn't fly. "moar-pager" is simply not something I want to type multiple times per day. And @halostatue, it's simply not true that "the existence of $PAGER
makes it so that for most things, one doesn't have to think about the name of moar
."
moar
's first release was in 2013. @halostatue, you said earlier here that MoarVM are unlikely to change their binary name since they released in 2014. Why would this be more likely for moar
that was released in 2013?
@notramo, you opened this ticket, informing me that "MoarVM" decided to use moar
as the name for their binary.
You said that MoarVM is more established than moar
, a sentiment echoed by @halostatue. This is what you believe, and it's within your rights to believe this, but I have found no data to support that belief. I also had no idea what MoarVM was before you started this thread.
"Raku" and nqp
are also brand new to me. Maybe others have long relationships with these things, but I had never heard about them before. That doesn't mean they are insignificant, but it's possible they are less of a thing than you think.
And of course you, as me and everybody else base your decisions on what you believe, which is also within your rights.
@halostatue I feel that you have taken some steps in the right direction, but my feeling is that before you stepped in this thread was 100% about demanding that moar
changes its name and 0% about solving the naming conflict.
Hope this helps somebody. /Johan
From the perspective of a distributor, just to comment on the point of how we normally handle such collisions (which I think got asked about earlier): we tend to give more weight to something which isn't a leaf in the dependency graph. A library or tool which is called by other programs is given more weight because renaming it requires both more work within the distribution but also upstream to help build systems find it and also adjust any runtime calls.
Let's say the moarvm
binary was renamed to moarvm
. What depends on it that would need to be updated?
I looked in https://github.com/macports/macports-ports and found:
moarvm
as moarvm
moarvm
as moarvm
Is there anything else that I'm missing?
Probably. Overall, the MoarVM
ecosystem is substantially more complex than that of moar
the pager, and while it might be preferable to you to not have the binary name changed by MacPorts, moar
is primarily a leaf dependency and not a foundational utility used by compilers and programmers who use those compilers alike, your related utilities riff
and ugrep
notwithstanding. The use of $PAGER
and shell aliases can absolutely make the name change irrelevant.
There has, as yet, been no discussion on the MacPorts ticket, but my recommendation on that ticket still stands, and if I find myself with an opportunity to explore it, will be the direction that I take with pull requests. If there is a preferred alternate name for moar
that you would like to see instead of moar-pager
, I can take that under consideration. If there are other packages known to be in MacPorts that use moar
in addition to riff
and ugrep
, I can look at modifying those as well.
It would be nice if such an alternative were blessed by you such that go install github.com/walles/moar/cmd/moar-pager@latest
or your preferred alternative name would work, because that would also mean you have updated riff
and ugrep
upstream to work with the blessed alternative. But I am as likely to rename the MoarVM
binary as I would be to rename a ruby
‡ binary.
As I said, if I can figure out how to make a port variant recognize that it may conflict with the default installation (that is, conflict moar -moar+pager
) but not a variant, then we can keep port install moar
installing moar
and use port install moar+pager
for people who wish to use both MoarVM
and moar
, the pager.
‡ I know that MacPorts actually builds ruby
as rubyMm
, but there is a version selection mechanism that will set ruby
to be the preferred version of rubyMm
as required. Because MoarVM
and moar
are unrelated, there would be no selection mechanism.
It struck me that very few people are likely to be affected by moarvm
's naming conflict.
As long as the moarvm
binary cannot be renamed to moarvm
, then I think your suggestion as I understood it is fine:
moarvm
as conflicting with moar
moar+pager
package for MacPorts that moarvm
does not conflict withA possible solution for MacPorts has been opened at macports/macports-ports#21604, including patches to ugrep and riff.
The Raku programming language interpreter is called MoarVM, with
moar
as the executable name.