Skip to content

scala-cli cache override bug #3523

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

Open
ankita-ndd opened this issue Feb 27, 2025 · 3 comments
Open

scala-cli cache override bug #3523

ankita-ndd opened this issue Feb 27, 2025 · 3 comments
Labels
bug Something isn't working coursier Issues tied with coursier integration.

Comments

@ankita-ndd
Copy link

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.

@ankita-ndd ankita-ndd added the bug Something isn't working label Feb 27, 2025
@Gedochao Gedochao added the coursier Issues tied with coursier integration. label Feb 27, 2025
@Gedochao
Copy link
Contributor

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

@ankita-ndd
Copy link
Author

ankita-ndd commented Feb 27, 2025

@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?

@Gedochao
Copy link
Contributor

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working coursier Issues tied with coursier integration.
Projects
None yet
Development

No branches or pull requests

2 participants