VirtusLab
scala-cli cache override bug
Version(s) scala-cli v1.6.2 release
Describe the bug
While invoking the scala-cli tool in our build, we use the following command and the flag --cache to avoid using the default cache location:
mkdir -p /tmp/coursier-cache
export COURSIER_CACHE="/tmp/coursier-cache"
mkdir -p /tmp/scalacache
"./$scala_cli_path" --power package --scala 3.3.1 --cache /tmp/scalacache $SCALA_OUT/ --output $output_jar --library \
--dependency com.thesamet.scalapb:scalapb-runtime_2.13:0.11.17 --dependency com.google.protobuf:protobuf-java:4.29.3
But the build errors out with
Error: java.nio.file.FileSystemException: /home/dev/.cache/scalacli/local-repo/.lock-1.6.2: Read-only file system
Verified that the location of $scala_cli_path is indeed pointing to the scala cli.
Appreciate any help!
To Reproduce The command used is:
"./$scala_cli_path" --power package --scala 3.3.1 --cache /tmp/coursier-cache $SCALA_OUT/ --output $output_jar --library \
--dependency com.thesamet.scalapb:scalapb-runtime_2.13:0.11.17 --dependency com.google.protobuf:protobuf-java:4.29.3
Expected behaviour
We expected the --cache flag will override looking into the home dir which is not permitted in our build system.
But the build errors out with
Error: java.nio.file.FileSystemException: /home/dev/.cache/scalacli/local-repo/.lock-1.6.2: Read-only file system
@ankita-ndd Can you provide the full stack trace?
Also, running with -v -v -v should increase verbosity, which might make it easier to find out what's going on.
Finally, which Scala CLI distribution are you using? (how did you install it? is it scala-cli or scala?)
@Gedochao thanks for helping us out here!
On running with -v -v -v, here's the complete stack trace
Exception in thread "main" java.nio.file.FileSystemException: /home/dev/.cache/scalacli/local-repo/.lock-1.6.2: Read-only file system
at java.base/sun.nio.fs.UnixException.translateToIOException(UnixException.java:100)
at java.base/sun.nio.fs.UnixException.rethrowAsIOException(UnixException.java:106)
at java.base/sun.nio.fs.UnixException.rethrowAsIOException(UnixException.java:111)
at java.base/sun.nio.fs.UnixFileSystemProvider.newFileChannel(UnixFileSystemProvider.java:224)
at java.base/java.nio.channels.FileChannel.open(FileChannel.java:309)
at java.base/java.nio.channels.FileChannel.open(FileChannel.java:369)
at scala.build.LocalRepo$.withLock(LocalRepo.scala:111)
at scala.build.LocalRepo$.localRepo(LocalRepo.scala:92)
at scala.cli.commands.shared.SharedOptions.buildOptions$$anonfun$1(SharedOptions.scala:439)
at scala.build.EitherCps$Helper.apply(EitherCps.scala:19)
at scala.cli.commands.shared.SharedOptions.buildOptions(SharedOptions.scala:306)
at scala.cli.commands.package0.PackageOptions.baseBuildOptions$$anonfun$1(PackageOptions.scala:181)
at scala.build.EitherCps$Helper.apply(EitherCps.scala:19)
at scala.cli.commands.package0.PackageOptions.baseBuildOptions(PackageOptions.scala:180)
at scala.cli.commands.package0.Package$.buildOptions(Package.scala:70)
at scala.cli.commands.package0.Package$.buildOptions(Package.scala:69)
at scala.cli.commands.ScalaCommand.run(ScalaCommand.scala:395)
at scala.cli.commands.ScalaCommand.run(ScalaCommand.scala:382)
at caseapp.core.app.CaseApp.main(CaseApp.scala:166)
at scala.cli.commands.ScalaCommand.main(ScalaCommand.scala:367)
at caseapp.core.app.CommandsEntryPoint.main(CommandsEntryPoint.scala:370)
at scala.cli.ScalaCliCommands.main(ScalaCliCommands.scala:125)
at scala.cli.ScalaCli$.main0(ScalaCli.scala:320)
at scala.cli.ScalaCli$.main(ScalaCli.scala:124)
at scala.cli.ScalaCli.main(ScalaCli.scala)
at java.base/jdk.internal.reflect.DirectMethodHandleAccessor.invoke(DirectMethodHandleAccessor.java:103)
at java.base/java.lang.reflect.Method.invoke(Method.java:580)
at coursier.bootstrap.launcher.a.a(Unknown Source)
at coursier.bootstrap.launcher.ResourcesLauncher.main(Unknown Source)
I'm using this scala-cli release https://github.com/VirtusLab/scala-cli/releases/download/v1.6.2/scala-cli
On thinking more about this - I think the root issue is that the environment in which we are trying to run scala-cli expects scala-cli to be hermetic. Is it possible to run scala-cli hermetically?
Is it possible to run scala-cli hermetically?
It should be possible to run without internet access, but I'm not sure your exact use case has been tested before. If it's indeed broken, I'll see if we can fix it for you. For now, need to find the time to investigate some more.