Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Also support the test configuration #186

Open
gzm0 opened this issue Apr 24, 2022 · 3 comments
Open

Also support the test configuration #186

gzm0 opened this issue Apr 24, 2022 · 3 comments

Comments

@gzm0
Copy link

gzm0 commented Apr 24, 2022

We are starting to use sbt-buildinfo in Scala.js core (scala-js/scala-js#4660) to replace a hand-built version of it.

However, we mostly need this in the test configuration. We can currently achieve this by:

  • No enabling BuildInfoPlugin
  • Adding BuildInfoPlugin.buildInfoDefaultSettings, BuildInfoPlugin.buildInfoScopedSettings(Test) to the relevant project's setting.

Should we add an "official" way of doing this?

@eed3si9n
Copy link
Member

eed3si9n commented May 1, 2022

Sure. I'd be happy to review a PR if you are up for sending one :)

@armanbilge
Copy link

I've needed this before too. My workaround has been to create a new, no-publish sub-project to enable BuildInfo and depend on it in the test scope of my other sub-projects. Example:
https://github.com/typelevel/bobcats/blob/48f65d5efbf0f8ecb49d4d9eda25e9f964d9735d/build.sbt#L105-L107

@gzm0
Copy link
Author

gzm0 commented May 15, 2022

IMHO the main challenge is the interface: Currently, BuildInfo generates relevant code by merely being enabled. However, since enabling a plugin is a per project setting and not a per configuration setting, this will not generalize.

A good interface would be to drop the default value of buildinfoKeys and make generation dependent on that key being non-empty.

However, this comes with major compatibility issues for existing builds:

  • Builds relying bn the default value will fail to compile (object missing).
  • Builds setting buildInfoKeys (without configuration scope) will fail to compile in the test configuration because the object will be duplicate.

Similar arguments apply to other keys (package, object name).

An alternative would be to introduce buildinfoEnable and set it to true in the compile config and false in the test config. However, the need to "double enable" really bothers me.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants