Asking for your feedback on sbt + Scala Center announcement

[jvican]

Thanks @fommil and @ShaneDelmore for your feedback!

@fommil

For now, I don’t even care about new features, just please move to a new version of scala so we can all let go of 2.10 (we can all still offer commercial support for legacy versions of scala, but remember we are almost all volunteers and it is burning us out).

Yes, I wholeheartedly agree. I know that for some of the Scala Center projects supporting 2.10 takes a considerable amount of our time. Keep the eyes open to the roadmap that sbt team will announce shortly, it happens that sbt 1.0 will be coming to our hands earlier than expected.

@fommil

Single jar download of sbt would also be very very useful and speed up the initial install of scala for beginners.

I would like to see one-jar installation, or at least a simplification of the published jars that are resolved. Apparently, the current design is due to the desire of having independent sbt modules that you can independently update (like Zinc). Related discussion here.

@ShaneDelmore

No support for putting a cache of dependencies in my repo for true offline mode. Related to User Stories: Offline mode and Dependency Locking · sbt/sbt Wiki · GitHub

Interesting! I was not aware of that document you link to. The dependency lock file is in our list, and I agree it’s important to add it to sbt. You already mention the most direct use case, offline mode, but I think that it would be wonderful for two things more:

• Bring build reproducibility. Module resolution will always bring the same result because it’s cached.
• Remove unnecessary dependency resolution, which is expensive. Currently, sbt spends time resolving dependencies when:
  • You change scala versions (cross-compiling) or projects with different scala versions.
  • You run sbt in your CI.

@eed3si9n and I have been discussing this several times in Gitter and this ticket. Swing by and let us know what you think about our current proposal.

@ShaneDelmore

Error messages from scalac are not obviously actionable for end users as most don’t understand the difference between scalac and sbt.

Any idea how could we fix this? It seems that the root of the problem is that they don’t see a clear distinction between sbt and Scala. I haven’t been in that position before, so I cannot imagine what could be done to make it more obvious. Perhaps you can reach out to those users (if you know them) and let us know what they think?

@ShaneDelmore

This model of development falls down quickly with SBT as you cannot easily write a test for it or set a breakpoint on it from IntelliJ which means you have to learn a new way of working to add that task you wanted to SBT, along with of course learning the mental model of SBT.

I am aware this is a real problem. I proposed to the sbt team to start adding built-in functionality to sbt to officially support these use cases. For instance, things like GitHub - dwijnand/sbt-project-graph: An sbt plugin to help visualise inter-project dependencies should IMO be ported upstream. I would like also a way to visualize sbt builds with graphs generated via dot (like GitHub - sbt/sbt-dependency-graph: sbt plugin to create a dependency graph for your project supports). Ideas along the same lines to ease sbt debugging are very much welcome!

@sjrd also proposed a way to add a dynamic inspect-tree option that would report on all the tasks and settings executed in a given run, opposed to the current inspect-tree that only shows static task dependencies. This task would run the task to “inspect”. It is useful when you start having things like Def.taskDyn that are not capable of showing its dependencies.