Should it pull down the latest unless you specify a Scala version like so: sbt --version=2.11.1 console
Currently it defaults to 2.10.
Currently I refrain from using it when outside of a project because sbt creates a target folder in the pwd anyway.
2 Likes
sbt 0.13 was released a long time ago. The next one would use Scala 2.12. I disagree as a principle on introducing the notion of "just use the latest."
If we think about how that would be implemented, that would be sbt randomly checking the Internet for the latest Scala version and then using that for your build. Thatās a bad experience for both serious projects and getting started new users since tutorial canāt be written reliablly.
1 Like
The overarching goal is to allow people to use the REPL without having to install the binaries. sbt console could be the easiest way to accomplish this. However, we also want people to be able to use sbt console offline. Perhaps it could use the latest cached version of Scala.
I donāt necessarily agree here. In 2017 Iād say the opposite, that realizing sbt console is using 2.10 (which was released 4 years ago) is more surprising than āsbt REPL thingyā using the most up-to-date version of Scala.
To say a bit more about the problem weāre currently trying to solveā¦ Weāre trying to figure out how we can, for extreme beginners to Scala, instruct them on how to (1) download sbt, and (2) get into a REPL to play around without needing a Scala project defined first.
Since sbt is the way to compile/run Scala, it would make sense that getting into a REPL would be as straightforward as possible.
2 Likes
Things I personally think would be nice: (maybe no one agrees with meā¦)
- You can do
sbt consoleorsbt replor something and get a Scala REPL with some more up-to-date version of Scala - If you called
sbt consoleetc in a folder without a project, it would be nice if there was notargetdirectory created in the current directory. (Maybe sbt could check if thereās an sbt project in the current directory, and if not, use some scratch target directory elsewhere that the user doesnāt have to bother with)
Again, the point is to focus on beginners.
1 Like
At least paulpās script has a flag
Even without paulpās script, you can always do:
sbt '++2.12.1 console'
But that doesnāt solve the target folder issueā¦
2 Likes
It also maybe isnāt the simplest thing to tell a beginner to do and hope that they remember. Something a bit more concise would be nicer I think.
I agree. A dedicated repl command sounds like a good idea then.
That way the console command keeps its current behavior. You canāt really test if you are in a project or not anyway since any folder is a valid sbt project, so it would be better to keep the two commands separate.
3 Likes
heathermiller http://contributors.scala-lang.org/users/heathermiller
January 30Things I personally think would be nice: (maybe no one agrees with meā¦)
- You can do sbt console or sbt repl or something and get a Scala
REPL with some more up-to-date version of Scala- If you called sbt console etc in a folder without a project, it
would be nice if there was no target directory created in the current
directory. (Maybe sbt could check if thereās an sbt project in the current
directory, and if not, use some scratch target directory elsewhere that the
user doesnāt have to bother with)
Another possiblity is that when SBT exits, if it didnāt generate anything
useful (e.g., it was only used for a repl session), it cleans up after
itself.
Not sure which is simpler to implement. Also itās possible this could be
solved at the bash script level.
1 Like
How about just amm? Ammonite works on all platforms I think, is simple to install, and defaults to 2.12.
2 Likes
Ammonite is awesome, and indeed Iād recommend it to beginners. But I guess Iām just optimizing for what we assume people have already installed ā focusing in particular on sbt, because to use Scala, you need sbt.
That said, it would be cool if sbt by default did the straightforward thing out of the boxā¦
I would also really like it if we could integrate and provide ammonite out of the box. Not only is it much better than the default shell, it actually provides a great environment for beginners since you can easily import libraries into the shell and start hacking straight away
1 Like
Again, I was focusing only on sbt. While ammonite is nice, the point of this thread is: assuming you are using sbt, it would be nice ifā¦
If you are advocating for ammonite to become the default REPL, thatās a totally different question, although itās a cool idea. For that though I guess we would have to ask @lihaoyi to participate in the SIP or SPP processes.
Iām happy to be involved, but I think the current state of Ammonite is that it needs more maintainership before we can even think about making it standard.
Although I think Iām doing a terrific, amazing job maintaining it (lots of people are talking about how good a job Iām doing) I think that including libraries with only one maintainer as a ādefaultā experience sounds to me like a recipe for bitrot and eventual abandonment.
Also, this is unfortunately incorrect:
Ammonite works on all platforms I think
While Ammonite scripts should work on all platforms, the REPL unfortunately does not Ammonite-REPL doesn't work on Windows Ā· Issue #119 Ā· com-lihaoyi/Ammonite Ā· GitHub
While I havenāt used windows for programming for a few years now, itās probably pretty common in the overall community. Unless someone makes this work, Ammonite wouldnāt be able to serve some large portion of Scalaās user base
2 Likes
something like sbt --latest console?
So only when running --latest sbt will check the latest, and otherwise it will default to some version that is agreed at the time the sbt is built.
1 Like
coursier launch scala:latest.stable, which you could wrap in a shell alias.
Also available are my little shell runners around that: https://github.com/dwijnand/scala-runners, which you can install with brew install --HEAD dwijnand/formulas/scala-runners.
2 Likes