Curl install launcher in your repo

[joan38]

I was recording this video today and thought we could shorted further how long it takes for people to start with scala.

Also I think the section Standalone launcher should be before Advanced Installation, what do you think?
Should we also rename scala-cli to scala?

[sjrd]

This doesn't work for all the people who will clone your repo in Windows. You're making it harder for them.

[joan38]

@sjrd I added the Windows "curl" now

[sjrd]

I think you misunderstood my comment. The problem is not that the instructions on Windows were missing. It's that if you are on Linux you will commit the executable for Linux, but then users on other systems won't be able to use your repo.

This is bad practice, honestly. System-dependent things should be installed at the system level. Everything else can fit in a repo.

[Gedochao]

@sjrd @joan38 While I don't have a strong opinion here, and I'm not sure if it is indeed a good or bad practice, it is most definitely a common one... It's exactly how Mill is recommended to be used (and indeed is in this very repository).

I'd be okay to include this in the doc, regardless.
Perhaps the disputable part is whether we should have the paragraph about recommending this practice, or is mentioning the links sufficient.

@tgodzik @kasiaMarek thoughts?

[sjrd]

It's exactly how Mill is recommended to be used (and indeed is in this very repository).

Yes, and it makes Mill builds typically unusable on Windows.

[Gedochao]

We do have a mill.bat script committed, as well as mill...
@philwalk any opinion on this?
to be fair, I do not dev on Windows and may be unaware of the pain points, here.

[sjrd]

If you actually have mill.bat and you update it, and it's tested in CI, then this build is fine.

I said "typically" because most people don't actually do that.

[joan38]

This PR only adds the commands for quickly setting up the launcher scripts. What people already do with cumbersome copy/past and chmod +x.

@sjrd's concern is valid, that's why I pushed a version with the commands to also download the script of opposite platforms.

[SethTisue]

We recommend committing a scala executable for each OS together with your code [...]

I really don't think we should encourage this. It's a rat's nest — not just different OS, but also different CPU architectures for each OS.

[joan38]

@SethTisue Only OS because the script takes care of the architectures

[SethTisue]

Oh, I misunderstood what you meant by "executable", sorry.

(If we are to give this advice, perhaps it would be better to say "launch script".)

[SethTisue]

There was a time when tons of sbt-based projects had an sbt launch script in-repo, but I've always seen this as a relic of the Mark Harrah era when there was no standard launch script. Once sbt-extras died and Eugene committed to shipping a standard launch script, pretty much everybody stopped including it.

The committed launch scripts had a terrible tendency to fall out of date, and Scala Steward doesn't know how to update them.

Though I can see that the issue can be debated one way or the other, I'm firmly in the camp that thinks that committing these scripts is actually bad practice. Build tools (and semi-build-tools like Scala CLI) should be installed at the system level.

If we want to document that some people feel differently, I wouldn't be strongly opposed, but as currently written, this PR presents it as standard practice. I think it is very much not standard practice at all.

[joan38]

as currently written, this PR presents it as standard practice

The sentence was in the Launcher section but I'm removing it since it's controversial.
This PR now only adds the commands to download the scripts.

[Gedochao]

LGTM

[philwalk]

We do have a mill.bat script committed, as well as mill

I agree with @sjrd w.r.t. problems on Windows. For anyone working from git-bash or other bash shell environments, a .bat file is not adequate. The following wrapper script (if placed in the bin directory with the .bat file) mostly solves the problem for me.

#!/bin/bash
exec "$0.bat" "$@"