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

Document usage of `ThisBuild` over `Global` #3652

Open
jvican opened this Issue Oct 20, 2017 · 3 comments

Comments

Projects
None yet
4 participants
@jvican
Member

jvican commented Oct 20, 2017

(edited by @dwijnand, previous title: "Add inGlobal to allow scoping settings globally")

problem

inThisBuild is a standard operation in any build.sbt and sbt plugin. However, there's no counterpart for scoping in Global.

expectation

I would like to have an inGlobal operation to scope there important keys that are true at the global level (organization, license, et cetera).

This would be the implementation of inGlobal, placed in Project.scala:

  def inGlobal(ss: Seq[Setting[_]]): Seq[Setting[_]] =
    inScope(Scope.GlobalScope)(ss)

notes

I would like to add this to the Scala Center spree that we're having at Lambda World next week.

sbt version: 0.13.x and 1.x

@Duhemm Duhemm added the Spree label Oct 20, 2017

@dwijnand

This comment has been minimized.

Show comment
Hide comment
@dwijnand

dwijnand Oct 20, 2017

Member

The difference between Global and build-level is relevant when you have more than one build. In that case you see that what you refer to as "true at the global level (organization, license, et cetera)" isn't (always) true - any build you add could easily have a different organization, license, et cetera.

The way I see it is Global scope should be used only for:

  • defining the default value of new keys
  • for build-agnostic keys, for instance things that configuration the behaviour of the task graph or commands processing engine. Like cancellable.

Therefore I think the absence of inGlobal is a good thing, to avoid misuse.

Member

dwijnand commented Oct 20, 2017

The difference between Global and build-level is relevant when you have more than one build. In that case you see that what you refer to as "true at the global level (organization, license, et cetera)" isn't (always) true - any build you add could easily have a different organization, license, et cetera.

The way I see it is Global scope should be used only for:

  • defining the default value of new keys
  • for build-agnostic keys, for instance things that configuration the behaviour of the task graph or commands processing engine. Like cancellable.

Therefore I think the absence of inGlobal is a good thing, to avoid misuse.

@jvican

This comment has been minimized.

Show comment
Hide comment
@jvican

jvican Oct 20, 2017

Member

The way I see it is Global scope should be used only for: defining the default value of new keys and for build-agnostic keys, for instance things that configuration the behaviour of the task graph or commands processing engine. Like cancellable.

I agree with this. I'm happy to close this ticket so long as this is explained in the sbt docs and people know that they should scope in ThisBuild always in build.sbt.

Member

jvican commented Oct 20, 2017

The way I see it is Global scope should be used only for: defining the default value of new keys and for build-agnostic keys, for instance things that configuration the behaviour of the task graph or commands processing engine. Like cancellable.

I agree with this. I'm happy to close this ticket so long as this is explained in the sbt docs and people know that they should scope in ThisBuild always in build.sbt.

@dwijnand

This comment has been minimized.

Show comment
Hide comment
@dwijnand

dwijnand Oct 20, 2017

Member

I agree. We'll use this issue to track that documentation improvement.

Member

dwijnand commented Oct 20, 2017

I agree. We'll use this issue to track that documentation improvement.

@dwijnand dwijnand changed the title from Add `inGlobal` to allow scoping settings globally to Document usage of `ThisBuild` over `Global` May 14, 2018

@eed3si9n eed3si9n added the x/waffle label Sep 18, 2018

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment