-
Notifications
You must be signed in to change notification settings - Fork 123
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
Simpler seed #2
Comments
I think it's trying to demonstrate some recommended best practices on an sbt build setup. How would you make it simpler? |
Most basic projects start out with little more than a few settings and dependencies:
A starter template doesn't really need additional concepts, but instead might add some pointers to documentation and explanation on when you need more abstraction in your build. |
agree with @jastice this example is horridly convoluted and only teaches a beginner to cargo cult and not how to use sbt. |
@SethTisue can we close this? |
There were already some rounds of inconclusive discussion about this at #4 and #9. I think we all got sort of exhausted by the back and forth, and it wasn't clear who had the authority to make a final call. https://github.com/scala/hello-world.g8 exists as the simpler alternative personally what I'd like to see happen is:
but it's not clear that anyone has the will to push their views through, so the status quo remains the status quo what ideal outcome do you have in mind? |
another, more modest change, that everyone could probably agree on as an improvement, at least, if not the ideal end point, would be:
|
I think bare setting like scalaVersion := "2.13.1" becomes a source of confusion because in a multi-project build, people would assume it means ThisBuild / scalaVersion := "2.13.1" There's really no reason to have two flavors of specifying the subproject. Maybe I just have to deprecate it like I had to for |
I'm well aware of the trap you reference, but it's only a problem once you move from a single-project to a multi-project build. You can learn a lot of Scala, and get a lot of value out of sbt along the way, before ever wanting or needing to know anything about multi-project builds at all. (I used Scala and sbt myself for years without ever learning that.) In the context of teaching Scala to newcomers, I think the move to a multi-project build is in the learner's distant future, so to prepare them for that move so early is simply a pedagogical mistake that 1) distracts the learner from more important issues at their stage of learning, and not incidentally 2) gives them an unnecessarily negative impression of sbt. |
I think there are different theories on learning, and some of the ones that influenced me encourages to have lots and lots of good example code. I guess the analogy would be mothers with higher education talking to toddlers with richer vocabulary, which studies have shown would improve the child's eventual vocabulary. In particular, the idea of scoping and throughout the getting started guide, like https://www.scala-sbt.org/1.x/docs/Basic-Def.html#How+build.sbt+defines+settings. I don't expect new users to understand the meaning of |
If bare |
Bare settings are up for a fresh round of discussion now at sbt/sbt#6217 |
new thread on bare style vs multiproject style at https://contributors.scala-lang.org/t/build-sbt-for-begginers/6615 |
This seed seems too complicated for a minimum sbt project, in the way it sets up the project and dependencies. I suggest changing this template to a minimal-boilerplate version and perhaps creating another that demonstrates more advanced concepts.
Ideally, we would be using this seed as the default template when creating an sbt project from IntelliJ IDEA. I would be happy to contribute appropriate changes if you agree.
The text was updated successfully, but these errors were encountered: