undefined | Better HN

0 pointseeperson11y ago0 comments

Have you tried SBT 0.13? I think it addresses some of your issues with SBT syntax. The DSL usage has been greatly simplified (many fewer operators to remember). Also, the identifiers are now the same in both the config files and the shell.

In older versions of SBT (SBT 0.7 and earlier) the configuration was done using immutable settings. In SBT 0.10 there was a switch to the current model. I believe this was done to make the configuration more declarative. A side of affect of this is that builds can now be easily parallelized without becoming nondeterministic. It also means that, in general, you shouldn't care what order tasks a re run in.

As far determining what keys are available in which scopes, I have always found this pretty easy to determine by using the 'inspect' command in the SBT repl. Although, perhaps I am not entirely under standing your issue here.

SBT does have a problem for specific cases when you do need tasks to run in a particular order. However, this is something that is currently intended to be addressed[1] in the SBT 1.0 release, which is scheduled for the end of this year.

[1] https://github.com/sbt/sbt/issues/1001

0 comments

acjohnson5511y ago

I'm on 0.13.5, and I honestly don't notice much of a difference. Maybe once projects and docs fully bring themselves up to date, it will be better, but I still see some keys and scopes that have hyphens in their names in the console. Looking up cryptic operators is also a huge pain. Since `<<=` is no longer emphasized, I couldn't find it anywhere within the current manual, and yet many StackOverflow answers and readmes recommend using it to add a dependency to an existing task.

It's easy to inspect a single setting with `inspect`, but it's very unwieldy to try to examine the entire dependency tree this way.

The very un-Scala-esque syntactic rules in build.sbt files also are a huge pain for anybody who just needs to dabble. Clearly, writing Build.scala files was a major drag, but it really feels to me that the answer should have been a better pure Scala API, rather than a DSL. It's a really leaky abstraction.

View an example of my pain here: http://stackoverflow.com/questions/24286551/get-assets-to-co...

eepersonOP11y ago

The old versions of the keys and scopes with the hyphens are still present for backwards compatibility. However, you don't need to use those.

Yeah, I can certainly understand your frustration about finding info for the '<<=' operator. This is an unfortunate side effect of cleaning up the API. All of the old examples uses it but now the documentation doesn't explain it up front.

It sounds like your problem with examining the dependency tree might be solved by one of the 'inspect' sub commands (tree|uses|definitions). Running 'inspect tree <command>' will give you the entire dependency tree for '<command>'.

I'm not sure I understand your last point. What do you mean by 'better pure Scala API, rather than DSL'? Do you mean that the SBT API is not very good? Do you mean that the '.sbt' files are annoying to use? I'm a little confused since the DSL is a Scala API.

j / k navigate · click thread line to collapse