-
Notifications
You must be signed in to change notification settings - Fork 1.1k
Support :dep ... to add library dependenceies in the Scala REPL, add helpful message to //> using dep "..."
#24131
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
base: main
Are you sure you want to change the base?
Conversation
|
The failure looks like a network flake |
|
I think we should extract the repl to be its own artifact before accepting this change. @Gedochao lets add splitting the repl from the compiler to next week's core. |
|
It makes a great deal of architectural sense for the REPL to be its own artifact. The REPL is conceptually separate, and most consumers of the compiler don't consume the REPL. (Making the separation in Scala 2 was a long term goal of @adriaanm's that he did a great deal of work on, but we just never got it over the finish line.) |
|
We will explore making REPL its own artifact, in which case the approach from this PR could work. |
|
Since this isn't a language feature, presumably we can introduce it anytime? It's only for interactive use so there's no backwards compatibility concerns |
Presumably, yes, but given that it's a rather big feature for the REPL, it would fit in a new minor better. |
|
Splitting the classpath into a separate jar probably is a minor release requirement - e.g. tooling like Scala CLI --with-compiler would need to be updated |
|
@lihaoyi this too will require a rebase now. |
| case NonFatal(e) => Nil // If parsing fails, fall back to empty list | ||
|
|
||
| /** Resolve dependencies using Coursier Interface and return the classpath as a list of File objects */ | ||
| def resolveDependencies(dependencies: List[(String, String, String)]): Either[String, List[File]] = |
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 can be improved in the future by supporting:
//> using repository ...https://scala-cli.virtuslab.org/docs/reference/directives#repository
|
This will need to wait until |
|
@lihaoyi you should be able to test by local publishing the binaries, i.e. don’t need to wait for bin/scala to work |
|
Testing manually via |
|
@lihaoyi in the CI failure it looks like coursier isn't on the classpath |
|
Actually maybe not yet, still fiddling with it |
//> using dep "..." directives in Scala REPL:dep ... to add library dependenceies in the Scala REPL, add helpful message to //> using dep "..."
|
@Gedochao @hamzaremmal @bishabosha I decided to go with
For now I left the This doesn't close off the possibility of supporting |
Co-authored-by: Jamie Thompson <bishbashboshjt@gmail.com>
Co-authored-by: Jamie Thompson <bishbashboshjt@gmail.com>
|
@lihaoyi we already have a |
|
I don’t think |
|
Another thought: if Currently it seems the error just says "Unrecognized directive"; it would be nice if it also said at that point which directives are supported, so it isn't a guessing game. |
Yup... we should perhaps do that once we do add support for the ones we want in the REPL ( |
|
@lihaoyi We discussed it on today's Scala Core.
|
This PR is a proof-of-concept implementation porting over the Ammonite
import $ivyfunctionality to the Scala REPL, using a:depsyntax, with an error message on the Scala-CLIusing depsyntax pointing at:dep. Once this lands, along with other related PRs (#24127, #23849) we can probably deprecate Ammonite and refer people to the main Scala REPL since it'll have acquired all the important featuresTested manually:
Both
io.get-coursier:interfaceandorg.virtuslab:using_directivesare zero-dependency Java libraries, and so can be used directly without worrying about binary compatibility. Both libraries are widely used in the Scala ecosystem (SBT, Mill, ScalaCLI, Bazel, ...) and should be pretty trustworthy and reliable