Moving to sbt mailing list, please remove scala user from replies.
I actually have a great deal of sympathy with both sides of this argument. Having been using scala and sbt for a while, sbt seems very easy to use to me, especially having tried to use maven for similar things at my last job.
That said, the pain of getting a new hire set up with a working system has made me realise just how horrible the process is at the moment. Case in point: after installing the typesafe stack the other day, I then had to go find a different copy of the launcher jar because the bundled one refused to play ball with 0.11.3.
Having got that working, I'm then sat trying to explain to someone what each of the seven files split across three directories does.
I understand the reasons and I'm certainly not suggesting I'm going to stop using sbt, but sbt certainly presents a barrier to entry for some people.
That said, being able to add a single line to a file, reload sbt and suddenly have magic dependency graphs diagrams is *fantastic*
Thanks for the replies, I'll follow up on the sbt mailing list. I thought this was a place to start, because the issue of adoption affects all Scala users.Josh: Good to know you guys are working on many of those issues. If someone could give me a hand, I'd want to understand what it takes to write an alternative build script engine around SBT.Daniel: ~/.sbt is pretty important. There are certain build plugins, such as the idea plugin, which you don't want to pollute every project with, but put on a global level. There are other global settings or organizational settings too, such as common repos. And even if you don't change those very often, the pain of changing them tends to discourage new comers.
On Thursday, October 4, 2012 6:43:59 PM UTC-7, Daniel Sobral wrote:I don't understand the complain about multiple files. You only need
*two* files: one for the project, another for the plugins. You can
choose between the simplified .sbt format or a full fledged .scala
format, but one can just set a standard for how to do things if people
are getting confused.
There's no need to put anything on ~/.sbt -- that's just something to
help people have things applied over all projects, and if rake doesn't
have something like that, then -- imho -- rake sucks.
I also wonder why do you change the project itself frequently enough
for that to be a hindrance, but I agree it's boringly slow when you
have to do it.
On Thu, Oct 4, 2012 at 8:13 PM, Evan Chan <vel...@gmail.com> wrote:
> Dear Scala community,
>
> I wanted to share my experience as someone trying to introduce Scala into
> our small company over the last year or so. My goal is not to start a
> flame war, but to improve the tools (particularly SBT) we all love and use.
>
> We have always been a Ruby shop. Everyone loves Ruby here. We started
> exploring Scala a year ago for higher performance applications, as certain
> things in Ruby (such as MapReduce jobs) are too slow. We use SBT, and a
> variety of editors (IDEA is the most common one, but some use vim, and some
> want to use Eclipse, so IDE standardization is out of the question).
>
> We have Scala in production now, but its use is relegated to high
> performance backend stuff. There is at least one very vocal Scala
> detractor. The feeling seems to be that the language is good, but the
> development and build tooling (esp SBT) is severely lacking, to put it very
> nicely. It seems to be a huge hindrance to those who want to explore doing
> Scala projects, where the reaction is "why would you even consider setting
> up a Scala project????" To summarize the complaints about SBT:
> - too many build files. build.sbt, project/Build.scala,
> project/plugins.sbt, project/project/Build.scala, and then there's the same
> structure repeated in ~/.sbt. People are very confused about what goes
> where.
> - related to the above, it's often impossible to understand where changes
> come in that impact build settings, due to the # of build files.
> - SBT is very slow whenever any change to the build project occurs, because
> it has to recompile and reiterate through dependencies of the build project,
> plus the same for the ~/.sbt project, etc.
>
> For comparison (if you are not familiar with rake, or gradle, etc.), rake
> builds things using one single Rakefile, it loads and builds instantly.
>
> Another point of comparison is Go! The same people who hate Scala's build
> tools are in love with Go, because of its lightning compilation speeds and
> simple build (no build files needed). So it's not a matter of static vs
> compiled, etc., but more a matter of tooling.
>
> However, it is clear that SBT is where the vast majority of build tooling in
> the Scala community is focused on, and is superior to its competition
> (gradle, buildr, etc.) in terms of actual build speed of source code itself
> (as opposed to build.sbt, etc.), triggered execution, community,
> scala-specific plugins, etc.
>
> So I have some suggestions for the Scala community regarding SBT, that would
> IMHO enhance its ease of use significantly and enable those of us wanting to
> push for Scala adoption in the startup sphere:
> 1. Clearly separate out SBT core functionality (compilation, dependency
> management, task execution) from the .sbt build files and environment
> 2. Make it easy to develop an alternative build file specification on top of
> the core functionality, so if someone wanted to develop a much easier,
> Rakefile-like alternative to .sbt files, they can
> 3. Focus on the simplest scheme possible for build files. Namely:
> a) one build file, not multiple ones in multiple hierarchies
> b) declare plugins and use them in the same file
> c) more of a convention for plugins, so I don't need separate lines
> like (addSbtPlugin(...); import org.someplugin.blah;
> seq(someplugin.newSettings:_*); )
> 4. I know many people love their Scala-based build files and may not like me
> for saying this, but I think dynamic languages are a much better fit for
> build scripts/files than compiled languages. You get much more
> instantaneous response.
>
> What do you guys think?
>
> Peace,
> Evan
--
Daniel C. Sobral
I travel to the future all the time.
--
You received this message because you are subscribed to the Google Groups "simple-build-tool" group.
To post to this group, send email to simple-b...@googlegroups.com.
To unsubscribe from this group, send email to simple-build-t...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/simple-build-tool?hl=en.
Moving to sbt mailing list, please remove scala user from replies.
I actually have a great deal of sympathy with both sides of this argument. Having been using scala and sbt for a while, sbt seems very easy to use to me, especially having tried to use maven for similar things at my last job.
That said, the pain of getting a new hire set up with a working system has made me realise just how horrible the process is at the moment. Case in point: after installing the typesafe stack the other day, I then had to go find a different copy of the launcher jar because the bundled one refused to play ball with 0.11.3.
That said, the pain of getting a new hire set up with a working system has made me realise just how horrible the process is at the moment. Case in point: after installing the typesafe stack the other day, I then had to go find a different copy of the launcher jar because the bundled one refused to play ball with 0.11.3.
- build.properties is not needed either if you use paulp's sbt-extras script, which lets you pass in the sbt version to use.
On Thu, 11 Oct 2012 19:35:54 -0700 (PDT)
nafg <nafto...@gmail.com> wrote:
Thanks for taking a look and providing feedback.
> Regarding the backticks, one possible concern is what if the scala code
> needs to use them? Would it be a possible alternative, to use indentation,
> like python?
I think the proposal says use double backticks for escaping, but I'm not sure supporting backticks in the build file is really necessary. (I know sbt uses `package`, but I think backticks for reserved words or including spaces isn't a good idea for normal usage and I'd like to move away from it.)
> Regarding the syntax in general, is there no way to get this much
> information in scala code, as a dsl, using macros? Perhaps it would require
> compiling more at a time (IIRC currently .sbt files only recompile changed
> lines), but is there any reason it's not possible?
It is indeed a good idea to consider a syntax that is still 99% Scala.
In my experience, macros are a huge amount of work. There aren't really that many advantages for a more complicated macro and there are plenty of disadvantages. As examples of disadvantages, they effectively define their own rules and the implementation is going to be opaque to more people than non-macro code. Someone would have to show otherwise with a prototype.
> Maybe something like:
>
> "sbt.version=0.13.0"
>
> def x = project {
> depends(a, c)
> aggregates(a,b,c)
> settings {
> demo := 33
> organization := "org.example"
> libraryDependencies += junitDep
> libraryDependencies += Seq( "org.example" % "demo" % "1.0" )
> }
> }
>
> A lot of things would be done differently than in the current proposal,
> perhaps, but in terms of the objectives, what's not possible?
A minor point is that it would be a lazy val instead of a def. I assume you propose using the name of the def to set the id of the project?
Before, the data structures were immutable and thus trivially thread-safe. You can understand Project("x", file("x")).dependsOn(x) because they are all plain Scala with no secret mutable state, implicit parameters, or thread locals or whatever it would take to implement the above. This is a semantic difference that would count against this approach.
Next, this would change := to mutate something as well, which would complicate compatibility. Dropping the comma in the external proposal was done because it was easier. I think in a Scala-base approach that preserving the comma and making settings accept normal, repeated parameters would fix this.
depends, aggregates, and settings now need to be visible without prefix. They are only valid in the context of the project method and this can only be checked at runtime.
So, I'm not sure this adds much over:
lazy val x = Project().
dependsOn(a,c).
aggregates(a,b,c).
settings(
demo := 33,
organization := "org.example"
)
The trailing . is perhaps unfortunate,
but it uses the same Scala types as is currently used in a Build.scala file without any semantic tradeoffs or magic.
It seems worth pursuing, though. Things that need to be addressed for this to move to the next step of being a feasible alternative:
1) defining new task/setting keys
2) defining plugins in the same file
3) compilation/loading model, including how multiple files are merged/imported
4) preserving the ability to programmatically manipulate settings in a build.sbt file
5) unified source/binary/internal dependency declarations
6) whether it is possible to have the equivalent of:
settings in x,a,b
scalaVersion := "2.8.1"
Having a plugin definition in the same file as the build rules out that file as being a pure Scala file*. The plugin definition has to be compiled and loaded and then used to compile and load the build definition. So, there has to be some non-Scala syntax somewhere that separates the two.
If the parsing rules are difficult to understand, let's improve them. Elsewhere in this thread is a proposal to have it more Scala-based, for example. Consider the original proposal along the lines of a Scala template. Most things are Scala expressions glued together by non-Scala syntax. The point is to be easier to document, easier to present to new users, and address the problems in the beginning of the proposal. If the current proposal doesn't work out, fine, but I think it is worthwhile to consider alternatives to the current situation.
I don't know if you mean the syntax, but if so, there is a branch with an improved syntax for defining tasks and settings that doesn't need the map/apply distinction or the <-prefixed methods like <<=. The branch is feature/task-syntax, it requires 2.10.0-RC1, and you can see Defaults.scala for a comparison with the current syntax:
https://github.com/harrah/xsbt/commit/fa0c303f679c15e346fdfcb4