1

Given a build.sbt which is committed to a code repository, what is a general pattern which allows users to override setting values defined in this script?

On the surface, this appears to have been answered in Where should local settings (per user, and not version-controlled) go in newer (0.10+) versions of SBT?. The answer there is to simply define two scripts in the same directory -- build.sbt and local.sbt, and rely on the fact that sbt will combine these scripts together. This may work for augmenting values (i.e., appending lists), but I don't see how it works for overriding the script value, since if a setting's value is set in both scripts, I don't know which of the two values will survive after sbt has combined the scripts.

It could be that I'm missing something very simple.

Community
  • 1
  • 1
JimN
  • 3,120
  • 22
  • 35

1 Answers1

0

I'd recommend using ~/.sbt/0.13 global directory where your .sbt files are processed during project load and after the other files in the project itself.

I found ~/.sbt/0.13/global.sbt a good place for global settings - the name always hints me for its purpose.

Jacek Laskowski
  • 72,696
  • 27
  • 242
  • 420
  • 1
    Is there any way to achieve a similar effect on a per-project basis? I suspect we probably need to override settings on a per-project (in addition to per-user) basis. – JimN Mar 15 '14 at 00:51