Archive this repo? - Githubissues

SethTisue commented 2 years ago

on Twitter @olafurpg said that was the plan:

cc @eed3si9n

olafurpg commented 2 years ago

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 commented 2 years ago

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 commented 2 years ago

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 https://github.com/coursier/apps/pull/119

SethTisue commented 2 years ago

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

the ticket to thumbs-up is: https://github.com/actions/setup-java/issues/195

dimisjim commented 2 years ago

I think what would solve our issues, would be a resolution to https://github.com/actions/setup-java/issues/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 commented 2 years ago

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

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

sideeffffect commented 2 years ago

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 commented 2 years ago

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

eed3si9n commented 2 years ago

@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 commented 2 years ago

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.

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

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 commented 1 year ago

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 commented 1 year ago

I would still suggest that this repo be archived.

vicaba commented 1 year ago

Agree to do both.

olafurpg / setup-scala

Archive this repo? #49