为什么通常为每个 Scala 项目安装 Scala，而不是在系统范围内安装？答案

【问题标题】：Why is Scala usually installed for each of your Scala projects rather than being installed system-wide?为什么通常为每个 Scala 项目安装 Scala，而不是在系统范围内安装？
【发布时间】：2020-03-14 17:59:22
【问题描述】：

我想知道为什么https://www.scala-lang.org/download/ 说

Scala 不寻常，因为它通常为每个 Scala 项目安装，而不是在系统范围内安装。

为什么 Java 不是这样？这种方式适用于 Java 项目吗？

谢谢。

【问题讨论】：

这样你在执行时就不会遇到愚蠢的问题，因为你正在运行它编译的版本的不同版本或其他常见的“它在我的机器上工作”问题。与其他语言不同的是，Scala 项目指定了所有依赖项及其相应版本，包括 scala 和构建工具本身 （因此您只需拉取任何项目即可工作，而您只需要 JRE 和 SBT脚本安装） 而且，通常，构建的工件包括它们的所有依赖项，包括 Scala 本身，因此它们可以在任何具有 JRE 的机器上运行。

标签： java scala

【解决方案1】：

如果你使用SBT，在项目的build.sbt指定的scalaVersion的基础上，它将Scala像其他常规库依赖一样处理并下载到

.ivy2/cache/org.scala-lang/scala-compiler
.ivy2/cache/org.scala-lang/scala-library
.ivy2/cache/org.scala-lang/scala-reflect

类似于常规库，比如猫

libraryDependencies += "org.typelevel" %% "cats-core" % "2.0.0"

最终会在

.ivy2/cache/org.typelevel/cats-core_2.13

我们还可以在 /usr/local/bin 下安装 Scala 的系统范围，但是 SBT 不会使用它，而是从 ~/.ivy2/ 读取

【讨论】：

谢谢。我只是重新审视你的回复。 SBT 是否需要 scala 解释器（非交互式运行 Scala 脚本或作为 REPL 交互式运行）或 JVM 字节码解释器？
@Tim sbt 以编程方式驱动进程内 scalac API，用于源代码到字节码的编译。它通过compiler interface 与编译器通信。最重要的是，它also通过Zinc进行增量编译，并根据定义的项目结构编译项目。
谢谢。我在询问 Scala 语言和 JVM 字节码（从 Scala 语言编译）的解释器，类似于命令 scala 和 java。我想知道 sbt 是否将解释器的 .jar 文件存储在 .ivy2 下？
@Tim 是的，解释器 (REPL) API 是从 scala-compiler.jar 依赖项调用的。
(1) JVM字节码解释器API（类似于scala/java命令）是否也在.ivy下的一些.jar文件中？ (2) 如果你想在 shell 中调用 Scala REPL，是 SBT 安装它，还是你下载 Scala 二进制版本并运行bin/scala？

【解决方案2】：

有一点是，在谈到 Java 时，我们需要区分 JRE 和 JDK。
JRE有JVM，所以它只是Java字节码的运行平台，JDK有编译器等开发工具。

Scala 安装已经带有编译器、解释器等。

两者都可以运行自己编译的代码，但 Java 需要在类路径上添加额外的 jar 才能运行 Scala 程序 (nicely described here)。

为每个项目单独安装 Scala 的另一个可能主要原因是 Scala 在其版本之间不完全兼容，即特定版本的 Scala 需要特定版本的库。
（Java 向后兼容）

【讨论】：