-
Notifications
You must be signed in to change notification settings - Fork 1.1k
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
Bundle scala cli in scala command #20351
Conversation
1e4a234
to
acbd467
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I can only comment on what's jumping at me. The timing is way too short to do a real review.
Even if I did find something it wouldn't get addressed and shipped in time at this point, so, to be blunt: why bother?
Edit: We can not guarantee that the Jar-based launcher works on JDK 17, so this must be |
A question is if a new scala-cli is released, will scala update it automatically, like |
The way it is currently implemented, the idea would be that each scala version is tied to a specific Scala CLI launcher. and Each scala release would come with whatever is the latest Scala CLI version at that moment |
|
cbcd575
to
46696d5
Compare
|
project/DottyVersion.scala
Outdated
|
||
val baseVersion = "3.5.0-RC1" | ||
|
||
val referenceVersion = "3.4.2-RC1" |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Is it right?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
we need a rebase
8ee4e6d
to
863b28b
Compare
@@ -23,7 +25,7 @@ class ClasspathTest { | |||
@Test def testWildcards(): Unit = | |||
val outDir = Files.createTempDirectory("classpath-test") | |||
try | |||
val compilerLib = "dist/target/pack/lib" | |||
val compilerLib = s"${if isWindows then "dist-win-x86_64" else "dist"}/target/pack/lib" |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Why is that change needed ? What is so specific to windows that we don't need to handle for others
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
because windows runners don't work with the jvm - but it should probably be the native launcher for each platform
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We should probably have tests for the jvm launcher and tests for all native launchers
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
but the jvm tests crash on windows because its JDK 8
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
What I meant is to run these tests with each native-launcher on each platform and then run the jvm-launcher on linux. But maybe it is a bit overkill to do that at the moment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Do we still care about testing the JVM launcher on Windows?
5f55261
to
aeafc08
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM
I just commented on some nitpicks, which can be addressed later in a future PR.
scala_args() { | ||
|
||
declare -a CLI_ARGS | ||
declare -a SCRIPT_ARGS | ||
declare DISABLE_BLOOP=1 | ||
|
||
while (( "$#" )); do | ||
case "$1" in | ||
"--") | ||
shift | ||
SCRIPT_ARGS+=("--") | ||
SCRIPT_ARGS+=("$@") | ||
break | ||
;; | ||
"clean" | "version" | "--version" | "-version" | "help" | "--help" | "-help") | ||
CLI_ARGS+=("$1") | ||
DISABLE_BLOOP=0 # clean command should not add --offline --server=false | ||
shift | ||
;; | ||
*) | ||
CLI_ARGS+=("$1") | ||
shift | ||
;; | ||
esac | ||
done | ||
|
||
if [ $DISABLE_BLOOP -eq 1 ]; then | ||
CLI_ARGS+=("--offline" "--server=false") | ||
fi | ||
|
||
echo "--power ${CLI_ARGS[@]} ${SCRIPT_ARGS[@]}" |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I still don't feel this is necessary... passing those arguments explicitly in the tests would make them more readable IMO, rather than embedding them in this script.
it's also easy to get confused where this script is being used.
This is a nitpick, however, we don't need to refactor it in this PR I think.
@@ -57,7 +57,7 @@ class TestScripts { | |||
s"bin/scalac script did not run properly. Output:$lineSep$dotcOutput" | |||
) | |||
|
|||
val (retDotr, dotrOutput) = executeScript("./bin/scala HelloWorld") | |||
val (retDotr, dotrOutput) = executeScript("./bin/scala -M HelloWorld") |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
this is slightly confusing, since just passing -M
to Scala CLI, without any inputs or -cp
will just fail.
I know it doesn't fail because -cp
is passed elsewhere, but this line looks like it should fail, technically.
sys.props.isDefinedAt("coursier.mainJar") | ||
|| sys.props.get("bootstrap.mainClass").contains("dotty.tools.MainGenericRunner") | ||
|
||
val silenced = sys.props.get("scala.use_legacy_launcher") == Some("true") |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We may want to document this prop clearly somewhere later, once we release this.
I'm also thinking an env variable could potentially be useful?
LEGACY_SCALA_RUNNER=true
or smth.
import java.nio.file.Paths | ||
|
||
def main(args: Array[String]): Unit = | ||
// def main(args: Array[String]): Unit = // MIGRATION: Scala CLI expects `*.sc` files to be straight-line code |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I wonder if it makes sense to keep this comment, or can we just remove it.
it's stated earlier that this is a Scala CLI script.
// def main(args: Array[String]): Unit = // MIGRATION: Scala CLI expects `*.sc` files to be straight-line code |
@@ -23,7 +25,7 @@ class ClasspathTest { | |||
@Test def testWildcards(): Unit = | |||
val outDir = Files.createTempDirectory("classpath-test") | |||
try | |||
val compilerLib = "dist/target/pack/lib" | |||
val compilerLib = s"${if isWindows then "dist-win-x86_64" else "dist"}/target/pack/lib" |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Do we still care about testing the JVM launcher on Windows?
(Not sure why I can't reply directly to your comment) We can't run JVM launchers on Windows due to the restriction on the Java version. We will keep releasing the JVM launcher anyways for other uses so it is good to test them too. |
Adapts the workflow to the changes in #20351
fixes scala#20098 Proposed changes to zip/targz archive: - in the `/bin` directory store an extra launcher for Scala CLI (either JAR, or native per platform). - `/bin/scala[.bat]` is modified to invoke Scala CLI stored in `/bin` - new `/maven2` directory, which stores all the Jars and POM files necessary (in maven repo style) for scala-cli to invoke scala compiler offline (using the `-r` launcher option). - CHOICE: either replace jar files in `/lib` by aliases to the corresponding jar in `/maven2`, OR delete `/lib` and update references from scripts. (Looks like symlinks are not portable, so probably we should encode the classpath in a file, or adjust slightly how we build the toolchain) - add platform specific suffixes to artefacts: - e.g. `scala-3.5.0-x86_64-pc-linux.tar.gz` (for the artefact that bundles the x64 linux launcher) --------- Co-authored-by: Hamza REMMAL <[email protected]>
fixes scala#20098 Proposed changes to zip/targz archive: - in the `/bin` directory store an extra launcher for Scala CLI (either JAR, or native per platform). - `/bin/scala[.bat]` is modified to invoke Scala CLI stored in `/bin` - new `/maven2` directory, which stores all the Jars and POM files necessary (in maven repo style) for scala-cli to invoke scala compiler offline (using the `-r` launcher option). - CHOICE: either replace jar files in `/lib` by aliases to the corresponding jar in `/maven2`, OR delete `/lib` and update references from scripts. (Looks like symlinks are not portable, so probably we should encode the classpath in a file, or adjust slightly how we build the toolchain) - add platform specific suffixes to artefacts: - e.g. `scala-3.5.0-x86_64-pc-linux.tar.gz` (for the artefact that bundles the x64 linux launcher) --------- Co-authored-by: Hamza REMMAL <[email protected]>
Backports #20351 to 3.5.0-RC2
This PR is based on #20351. The idea is to use `sbt-native-packager` instead of `sbt-pack` since it has the ability to generate `.msi` files. [test_msi]
fixes #20098
Proposed changes to zip/targz archive:
/bin
directory store an extra launcher for Scala CLI (either JAR, or native per platform)./bin/scala[.bat]
is modified to invoke Scala CLI stored in/bin
/maven2
directory, which stores all the Jars and POM files necessary (in maven repo style) for scala-cli to invoke scala compiler offline (using the-r
launcher option)./lib
by aliases to the corresponding jar in/maven2
, OR delete/lib
and update references from scripts. (Looks like symlinks are not portable, so probably we should encode the classpath in a file, or adjust slightly how we build the toolchain)scala-3.5.0-x86_64-pc-linux.tar.gz
(for the artefact that bundles the x64 linux launcher)