Name conflicts with MoarVM

[notramo]

The Raku programming language interpreter is called MoarVM, with moar as the executable name.

[walles]

I don't know what I should do with this information.

[Techcable]

Maybe add an alias to the binary, like moar-pager?

[walles]

Do you have any links to how the MoarVM people are dealing with this?

I should be able to follow their lead.

[walles]

I don't have a good solution, but my thoughts right now are:

1. 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 :).

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

[walles]

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.

[notramo]

Why should they rename it? Their project is more established than this one.

[walles]

@notramo, please read my previous comment on this: #143 (comment)

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.

[halostatue]

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:

1. renaming the port from moar to moar-pager
2. installing as 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.

[walles]

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.

[halostatue]

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.

[walles]

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.

[halostatue]

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.

[walles]

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.

[walles]

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

[thesamesam]

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.

[walles]

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:

• https://github.com/Raku/nqp would need to learn how to find moarvm as moarvm
• https://github.com/rakudo/rakudo would need to learn how to find moarvm as moarvm

Is there anything else that I'm missing?

[halostatue]

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.

[walles]

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:

1. Already done, I like: You mark moarvm as conflicting with moar
2. You might make an alternative moar+pager package for MacPorts that moarvm does not conflict with

[halostatue]

A possible solution for MacPorts has been opened at macports/macports-ports#21604, including patches to ugrep and riff.