Skip to content
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

Open
jastice opened this issue Nov 22, 2016 · 12 comments
Open

Simpler seed #2

jastice opened this issue Nov 22, 2016 · 12 comments

Comments

@jastice
Copy link

jastice commented Nov 22, 2016

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.

@dwijnand
Copy link
Member

I think it's trying to demonstrate some recommended best practices on an sbt build setup.

How would you make it simpler?

@jastice
Copy link
Author

jastice commented Nov 22, 2016

Most basic projects start out with little more than a few settings and dependencies:

organization := "com.example",
scalaVersion := "2.12.0"

libraryDependencies ++= Seq(
  "org.scalatest" %% "scalatest" % "3.0.0" % "test
)

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.

MasseGuillaume added a commit to MasseGuillaume/scala-seed.g8 that referenced this issue Jan 31, 2017
MasseGuillaume added a commit to MasseGuillaume/scala-seed.g8 that referenced this issue Jan 31, 2017
@pfn
Copy link

pfn commented Feb 9, 2017

agree with @jastice this example is horridly convoluted and only teaches a beginner to cargo cult and not how to use sbt.

@Philippus
Copy link
Member

@SethTisue can we close this?

@SethTisue
Copy link
Member

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:

  • move/rename scala/scala-seed.g8 to sbt/sbt-seed.g8
  • rename scala/hello-world.g8 to scala/scala-seed.g8

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?

@SethTisue
Copy link
Member

SethTisue commented Oct 1, 2019

another, more modest change, that everyone could probably agree on as an improvement, at least, if not the ideal end point, would be:

  • update the READMEs of both repos to:
    • briefly explain the repo's purpose
    • link to the other repo, for those who want the different purpose

@eed3si9n
Copy link
Member

eed3si9n commented Oct 1, 2019

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 project/Build.scala.

@SethTisue
Copy link
Member

SethTisue commented Oct 1, 2019

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.

@eed3si9n
Copy link
Member

eed3si9n commented Oct 1, 2019

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

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 scalaVersion to ThisBuild is done from the very first step of the documentation in "sbt by example" - https://www.scala-sbt.org/1.x/docs/sbt-by-example.html#Set+ThisBuild+%2F+scalaVersion+from+sbt+shell

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 ThisBuild, just as I don't expect them to fully comprehend exactly what := is doing, and that's ok. To some degree that's the purpose of sbt new command anyway. To start with a template.

@dwijnand
Copy link
Member

dwijnand commented Oct 1, 2019

If bare scalaVersion := "2.13.1" meant in ThisBuild and scopes would dynamically dispatch then there wouldn't be this problem. That would be a worthy goal.

@SethTisue
Copy link
Member

Bare settings are up for a fresh round of discussion now at sbt/sbt#6217

@SethTisue
Copy link
Member

new thread on bare style vs multiproject style at https://contributors.scala-lang.org/t/build-sbt-for-begginers/6615

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

6 participants