Allow users to reload and automatically reapply settings modified by set

[jvican]

problem

I agree this is not a major feature, but I find it important for sbt to be consistent.

Sbt provides lots of functionality around the session and the ability to control the modifications to the build that have been done via set. Let's see it:

clear, clear-all

	Removes temporary settings added using 'set' and re-evaluates all settings.
	For 'clear', only the settings defined for the current project are cleared.
	For 'clear-all', all settings in all projects are cleared.

list, list-all

	Prints a numbered list of session settings defined.
	The numbers may be used to remove individual settings or ranges of settings using 'remove'.
	For 'list', only the settings for the current project are printed.
	For 'list-all', all settings in all projets are printed.

remove <range-spec>

	<range-spec> is a comma-separated list of individual numbers or ranges of numbers.
	For example, 'remove 1,3,5-7'.
	The temporary settings at the given indices for the current project are removed and all settings are re-evaluated.
	Use the 'list' command to see a numbered list of settings for the current project.

save, save-all

	Makes the session settings permanent by writing them to a '.sbt' configuration file.
	For 'save', only the current project's settings are saved (the settings for other projects are left alone).
	For 'save-all', the session settings are saved for all projects.
	The session settings defined for a project are appended to the first '.sbt' configuration file in that project.
	If no '.sbt' configuration file exists, the settings are written to 'build.sbt' in the project's base directory.

In my personal case, I always have a long-running instance of sbt. I use it across different work days. During my work session, I do modifications to the build that I want to persist across the session, no matter if I reload. Reloading is required to add new plugins, modify versions of project dependencies, etc.

When I'm forced to reload, I usually spent some time finding the previous set commands and applying them one by one (note that doing so in just one set instruction is possible but not often since the set executions are incremental and unrelated to each other).

expectation

Right now, reload reloads the build from a clean slate and throws away my modified settings "at runtime" via set.

I'd like that sbt includes a way for me to persist these settings across different reloads. That can come in two different shapes (they are not necessarily exclusive, they can both be implemented if deemed appropriate):

1. Have a global setting that I can turn on and that will not throw these settings away.
2. Add a session reload that will do a reload keeping my current session.

sbt version: all sbt versions.

[eed3si9n]

During my work session, I do modifications to the build that I want to persist across the session, no matter if I reload.

Could you describe your typical work day set scenario as repro steps? Do you enable compiler flag or do you bring in library dependencies?

This might be a tricky one if we are partly depending on this amnesia for things like ++ to work. Let's say you've ran:

> set scalaVersion := "2.11.11"
> ++2.12.3

which one wins?

[jvican]

Could you describe your typical work day set scenario as repro steps? Do you enable compiler flag or do you bring in library dependencies?

Those last two are common use cases. I also change scala versions a lot, and I want them to be persisted. I find that the feature I'm adding is especially useful when fiddling with interactions between the settings that i've just added to the build (like a compiler plugin) and the settings I've added via set.

This might be a tricky one if we are partly depending on this amnesia for things like ++ to work. Let's say you've ran.

Good point. In my view, ++2.12.3 is just an alias of set scalaVersion := "2.12.3". The implementation of the feature I'm proposing would treat it as such. I think this is the only command that is problematic.

[dwijnand]

I agree this would be a useful feature to add. I propose we add it as a flag to reload. Perhaps reload keep-session or some such.

[dwijnand]

/cc @edmundnoble who could've used this too when he wanted to add (and then remove) some session settings and use reload at the same time, in a custom command - having a reload keep-session would've given him more options.