New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Do not use `perl6` as executable #2095

Closed
zoffixznet opened this Issue Jul 18, 2018 · 5 comments

Comments

Projects
None yet
5 participants
@zoffixznet
Contributor

zoffixznet commented Jul 18, 2018

The other day someone pointed out to me that it's weird that you install Rakudo, but execute it with perl6 binary.

What do you think of renaming it to something else on 6.d release? It'll be a fairly visible occasion for such a core change and will also coincide with the creation of the marketing alias for the language. The perl6 executable will coexist with the new binary for backcompat reasons until 6.e release (end of 2019), and after that, only the new binary will exist.

I couldn't care less what the other binary name is, as long as it's fairly short.


As the well-known mantra goes, Rakudo is a Perl 6 compiler and not the Perl 6 compiler and we try to maintain the language separate from any particular implementation.

However, Rakudo does have an unfair advantage to other compilers by claiming perl6 as its executable, thus inferring it is THE perl6 and the rest of the implementations have to choose their own names. The problem is also slightly exacerbated from a legal standpoint, as Rakudo's license requires any modified versions to use a different name and installation to not conflict with the original version. While the license provides other options for that clause, Rakudo's claiming perl6 name to itself makes it more difficult for other implementations to be installable under the same name (presumably they'd use part of Rakudo's code and not write everything from scratch, and thus would be bound by the license), but if they can't claim perl6 executable name, then we're back at the original issue of rakudo implying it's THE Perl 6 compiler.

The other benefit of renaming the executable is avoiding accidental use of perl instead of perl6 for executing scripts.

@ijneb

This comment has been minimized.

Show comment
Hide comment
@ijneb

ijneb Jul 18, 2018

I back this change, it makes sense. The main choices that come to mind for me are rkd, rak, and kudo.

ijneb commented Jul 18, 2018

I back this change, it makes sense. The main choices that come to mind for me are rkd, rak, and kudo.

@jnthn

This comment has been minimized.

Show comment
Hide comment
@jnthn

jnthn Jul 18, 2018

Member

No.

For one, this will cause a huge amount of breakage to numerous scripts that invoke perl6. You might be able to PR stuff that's public, but I'm surely not the only one with a bunch of internal scripts I'd have to fix up.

Moreover, I don't see the problem. Rakudo only claims it if you install Rakudo. Otherwise, you're free to install something else. Other languages even have tooling to let you move between different implementations, so for example you can have your ruby actually be TruffleRuby. As I remember it, .Net Core also has a tool like this. Your java might be OpenJDK or the Oracle provided version. And so on.

Considering those things, having a common entrypoint actually aids people trying alternative implementations with their existing setup, because all they have to change is what the perl6 in their path points to.

Member

jnthn commented Jul 18, 2018

No.

For one, this will cause a huge amount of breakage to numerous scripts that invoke perl6. You might be able to PR stuff that's public, but I'm surely not the only one with a bunch of internal scripts I'd have to fix up.

Moreover, I don't see the problem. Rakudo only claims it if you install Rakudo. Otherwise, you're free to install something else. Other languages even have tooling to let you move between different implementations, so for example you can have your ruby actually be TruffleRuby. As I remember it, .Net Core also has a tool like this. Your java might be OpenJDK or the Oracle provided version. And so on.

Considering those things, having a common entrypoint actually aids people trying alternative implementations with their existing setup, because all they have to change is what the perl6 in their path points to.

@zoffixznet

This comment has been minimized.

Show comment
Hide comment
@zoffixznet

zoffixznet Jul 18, 2018

Contributor

a common entrypoint actually aids people

👍

Contributor

zoffixznet commented Jul 18, 2018

a common entrypoint actually aids people

👍

@zoffixznet zoffixznet closed this Jul 18, 2018

@AlexDaniel

This comment has been minimized.

Show comment
Hide comment
@AlexDaniel

AlexDaniel Jul 19, 2018

Member

FWIW we already have implementation-specific executables, in rakudo that's perl6-m and perl6-j. In debian if you install rakudo it will give you both perl6 and perl6-m. I think there are enough letters for non-rakudo implementations to use.

Member

AlexDaniel commented Jul 19, 2018

FWIW we already have implementation-specific executables, in rakudo that's perl6-m and perl6-j. In debian if you install rakudo it will give you both perl6 and perl6-m. I think there are enough letters for non-rakudo implementations to use.

@rafaelschipiura

This comment has been minimized.

Show comment
Hide comment
@rafaelschipiura

rafaelschipiura Jul 19, 2018

Distros have specific methods to install programs that want the same executable and have only of them claim it. So it can be done without touching $PATH even.

rafaelschipiura commented Jul 19, 2018

Distros have specific methods to install programs that want the same executable and have only of them claim it. So it can be done without touching $PATH even.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment