Archive this repo?

[SethTisue]

on Twitter @olafurpg said that was the plan:

• https://twitter.com/olafurpg/status/1449455082614009863
• https://twitter.com/olafurpg/status/1449458576393654281

cc @eed3si9n

[olafurpg]

I am OK with archiving this project, but it's used in 905 public repos (https://sourcegraph.com/search?q=context:global+olafurpg/setup-scala+lang:yaml+select:repo+count:10000&patternType=literal) so I want to do it carefully and communicate the migration clearly. There shouldn't be any need for users to migrate either if they're happy with this action. The migration path will be something like this:

• use built-in sbt and java that are included by default with the GH Action runner, OR
• use https://github.com/coursier/setup-action if you need custom JDK installation

WDYT? cc/ @alexarchambault @laughedelic

[olafurpg]

I just took a look at https://github.com/actions/setup-java and it doesn't support GraalVM, which is a blocker to recommend it as an alternative IMO. I think coursier/setup-action provides a better migration path.

[laughedelic]

The migration path will be something like this:

• use built-in sbt and java that are included by default with the GH Action runner, OR
• use coursier/setup-action if you need custom JDK installation

Overall 👍 but I would refine like this:

• if you don't have any special requirements, use what's already on the runner (no need for any setup actions): Adopt OpenJDK 11 and the latest official sbt
• if you just need to switch Java version, use actions/setup-java, because it will use the runner cache and won't make unnecessary downloads (e.g. switching to Adopt OpenJDK 8 doesn't take any time)
• in any other case use coursier/setup-action to install a custom JDK and/or sbt (or other build tools)
  • there is a little catch that coursier installs another distribution of sbt, why I didn't recommend it as a default. but it will hopefully change soon with Fix coursier/coursier#1957: Always use the original sbt launcher. coursier/apps#119

[SethTisue]

I just took a look at actions/setup-java and it doesn't support GraalVM

the ticket to thumbs-up is: actions/setup-java#195

[dimisjim]

I think what would solve our issues, would be a resolution to actions/setup-java#266

The resolution would be one of the following:

• revamp this project to extend itself from setup-java, keeping all JDK/JRE options intact, like GraalVM, etc
• a new project, possible called setup-sbt, that ideally bases itself on setup-java (or anything else, if deemed appropriate) (https://github.com/Jtalk/setup-sbt just pulls the sbt binary and assumes that some JVM already exists, which is too simplistic)

Assuming one of the above 2 is done, then this project can either continue to exist, in that newly revamped form, or be replaced by a new, setup-sbt/scala one. I'll start this via: https://github.com/dimisjim/setup-sbt
Whoever wants to support this effort, cya there!

[sideeffffect]

My 2 cents as a humble Scala user.

I think that it would be the best for the whole Scala community if there were exactly one blessed GitHub action that would be also described in official Scala documentation. We can't prohibit people from experimenting with other GH Actions or custom scripts, but that's on them. It would be also great if Scala Center could commit to maintaining such Action, so that people can feel comfortable relying on it in the long term. Frequent hoping (and the fear there of) between different scaffolding solutions like GitHub Actions causes unnecessary friction. Fractured landscape of competing solutions (with unclear future and feature set) is hard to navigate, especially for beginners.

The official Scala GitHub Actions ideally

• would setup everything for Scala development (Scala/JVM to be precise)
• that includes installing a JVM, chosen by the user; it could rely on setup-java to do that; or maybe not, if setup-java doesn't contain useful features like installing GraalVM or what
• it should avoid using Jabba because it is unmaintained/lagging; perhaps a solution maintained by the wider Java community like https://github.com/foojayio/discoapi would be better ? CC @HanSolo
• the default JVM should be 8, so that the artefacts built, tested and published via this Action work on most JVM versions as reasonably possible; it's too easy to use Java 11 API in a Scala library only to find out it crashes when used on Java 8
• it would optionally setup everything needed for Scala.js and/or Scala Native
• besides installing sbt (or just a launcher script) it would also install mill (or just its launcher script) or other relevant tools (or launchers)
• it would get the blessing from relevant Scala institutions and get documented on the official places

Is https://github.com/coursier/setup-action supposed to be (or to become) such official Scala setup Action? What features described above is it currently lacking? @alexarchambault

Overview of current setup solutions

• https://github.com/coursier/setup-action
• https://github.com/olafurpg/setup-scala
• https://github.com/actions/setup-java
• https://github.com/japgolly/setup-everything-scala
• https://github.com/Jtalk/setup-sbt
• https://github.com/dimisjim/setup-sbt
• And maybe many others...

CCing @bvenners and @tpolecat as the Community representatives with Scala Center

[sideeffffect]

For the record @japgolly intends https://github.com/japgolly/setup-everything-scala to be such one stop solution for everything Scala related. But it doesn't support Scala Native, at least yet.

https://old.reddit.com/r/scala/comments/s5h3wb/should_there_be_a_single_setupscala_github_action/?#hszd7jl

[japgolly]

Speaking of which, can anyone please point me to a GHA for Scala Native? Me googling around didn't turn up anything.

[eed3si9n]

@japgolly See for example the repo for scopt/scopt (https://github.com/scopt/scopt/blob/560142e47fe17336f3fd29fbca3861ce4e222268/.github/workflows/ci.yml). I can call

sbt -v +scoptNative/test

without any additional setup on top of "ubuntu-latest".

I think historically you needed:

sudo apt-get update
sudo apt install clang libunwind-dev libgc-dev libre2-dev
sbt +scoptNative/test

But as far as I can tell, this is no longer required. I am not sure if this is due to ubuntu-latest getting more things, or Scala Native requiring less things.

For Windows, you might want to look at what Scala Native's repo does (https://github.com/scala-native/scala-native/blob/v0.4.3/.github/actions/windows-setup-env/action.yml).

[sideeffffect]

without any additional setup on top of "ubuntu-latest".

I think historically you needed:

I think the situation might be radically different if you want to build an actual application, like a CLI tool. See recent experience of @keynmol

After fighting with GHA for the entire day, one thing is clear.

1. A setup-scala-native GH action is needed with configurable LLVM version
   Setup for MacOS, Ubuntu, and Windows is wildly different, and nobody should be repeating it (I have it in 4 builds now).

2. An example of a CLI application with full deployment (build for 3 platforms and upload to GH release assets)

(2) is a major ballache because you need to build binaries on all three platforms and then upload from a separate job - you get into a lot of "fun" shit with artifact names and GHA's > conventions

In contrast, Node.js' pkg tool builds all platform binaries from the same infra and it's a much nicer experience.
Obviously not comparable because all it does is download a particular node executable and embed the JS files into it, but still - it's a reference point.

https://discord.com/channels/632150470000902164/635668881951686686/1008088682638626816

[vicaba]

Hi,
Is this action still deprecated? I would say so based on the comments of this issue, and the fact that there is a v14 of this action but it is not published (I am almost new to github actions, apologies if I am mistaken on that). Also, in the v14 tag description (https://github.com/olafurpg/setup-scala/releases/tag/v14) there is a deprecation message.
If the action is deprecated, I would suggest adding such message to the README. I can make a PR if you agree.

[SethTisue]

I would still suggest that this repo be archived.

[vicaba]

Agree to do both.