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.
It's also in the works whether we'd want to do it in 3.8 (for //> using dep to be available in the new 3.9 LTS later), or should this feature wait for 3.10.
@lihaoyi this may take us some time, we'll comment on this PR once a strategy gets established.
cc @WojciechMazur

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

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.
We've yet to decide how to go about this.

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.

This will need to wait until bin/scala is wired up before we can rebase and test it

@lihaoyi you should be able to test by local publishing the binaries, i.e. don’t need to wait for bin/scala to work

@lihaoyi we already have a :jar command, which adds a local dependency to the REPL's classpath (check #22343)
I'd be more leaning towards extending that functionality (possibly with :dep as an alias), rather than introducing a completely new REPL command for something very similar/adjacent
That being said, while I think having //> using dep <dependency> syntax is very much desired (rule of least surprise - people expect that to work and have been surprised it doesn't work for a long time), I'm not sure we want a :dep.
Adding it to the next Scala Core meeting agenda.

I don’t think :jar is much of a precedent since I think virtually nobody uses it or even knows about it; I cannot recall it ever being mentioned even a single time in forums or chat

Another thought: if //> using dep ... works, will create a user expectation that other using directives might work as well, such as //> using option ....

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.

Another thought: if //> using dep ... works, will create a user expectation that other using directives might work as well, such as //> using option ....

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 (//> using dep, perhaps //> using repository).

@lihaoyi We discussed it on today's Scala Core.

• the :dep approach is fine.
• it's okay to keep it separate from :jar.
• we'd like //> using dep down the line, but perhaps we can do it one step at a time.
  Thanks for putting so much effort into the REPL, by the way.

Since this seems to have approval, could someone do the honors and squash-merge it for me, since I don't have commit permissions