allow global plugins / settings

[cvogt]

related gitter discussion https://gitter.im/cvogt/cbt?at=576b55c4fac963084de1e6da

one way to do it

CbtBuild extends LocalPlugins ( or some name like that, mixing this in could be generated by CBT ) trait LocalPlugins is a trait somewhere in your cbt folder, that is not registered in git cbt generates it when it is not there, otherwise it doesn’t touch it you can use it to extend whatever plugins you want or inject default overrides

[megri]

I'm interested in a discussion about this!

One idea:

1. Look for a source-file containing object Plugins extends <desired plugins> from one or several paths (~/.cbt, /usr/local/.cbt etc)
2. If found, compile them with an added package path relevant to where they originate from, like cbt.user.home.Plugins and cbt.user.global.Plugins
3. Compile empty cbt.user.home.Plugins/cbt.user.global.Plugins extending some NoopPlugin if either is missing
4. Add scalacOptions to BaseBuild by introducing a new member final def resolvedScalacOptions = scalacOptions ++ cbt.user.home.Plugins.scalacOptions ++ cbt.user.global.Plugins.scalacOptions, possibly checking for duplicates and crashing or warning if found.

By resolving https://github.com/cvogt/cbt/issues/521 a stable interface for plugins can be established, making this predictable.

[cvogt]

I tend to think plugins should live under cbt's own directory somewhere, not the user's home, so it is possible to support multiple cbt versions easily, without disambiguating inside of the home directory by version number again like sbt does.

I think if it is a trait that is mixed into BaseBuild, things become easier, because you don't need to add things like cbt.user.home.Plugins.scalacOptions to BaseBuild.

And I think if it's missing, cbt can just generate a stub, that people can start putting stuff into?

WDYT?

[megri]

Good argument! A .gitignored template file could be forcibly added to the repository instead of having it generated.

Another issue that comes to mind is scoping: most plugins should be enabled for all builds, but a plugin that for instance generates project-files for IDEs should only be included once.

Is there some way to handle this currently?

[cvogt]

A .gitignored template file could be forcibly added to the repository instead of having it generated.

exactly

Most plugins should be enabled for all builds? What do you mean?

What does included once mean, how can things be included more than once?

[megri]

Maybe I'm overthinking it.

My reasoning was that you may want to enable some plugin for all BaseBuilds in a multi-project build, while another plugin should only be registered once for the root build.

For instance, generating an IntelliJ project file is something you want to happen only for the BaseBuild that aggregates other builds in your project, while a linting plugin should add scalacOptions to all sub-projects if you desire to compile and run them separately.

[cvogt]

So far my thinking was not to add any magic for this at all. It's inheritance. As a user, if you want the same thing in several places, use Scala for re-use, e.g. create a trait which mixes in all the plugins you want and mix that trait into all of your sub builds. Same for scalacOptions, etc.