[sbt 1.0] Remove old operators `<<=`, `<+=`, and `<++=` #2711

Merged
merged 2 commits into from Aug 30, 2016

Conversation

Projects
None yet
9 participants
@eed3si9n
Member

eed3si9n commented Aug 26, 2016

<<=, <+=, and <++= will be removed.

The recommended migration path is sbt 0.13 style := macro.

These operators are carryover from sbt 0.10 - 0.12, and haven't been on the Getting Started guide since sbt 0.13.0 came out in 2013.

/review @dwijnand, @jsuereth, @Duhemm

This PR is on top of #2710

@hseeberger

This comment has been minimized.

Show comment
Hide comment
Member

hseeberger commented Aug 26, 2016

+1

@magro

This comment has been minimized.

Show comment
Hide comment
@magro

magro Aug 26, 2016

How would this be rewritten:

compile in Jmh <<= (compile in Jmh) dependsOn (compile in Test)

(from https://github.com/ktoso/sbt-jmh)

magro commented Aug 26, 2016

How would this be rewritten:

compile in Jmh <<= (compile in Jmh) dependsOn (compile in Test)

(from https://github.com/ktoso/sbt-jmh)

@ccmtaylor

This comment has been minimized.

Show comment
Hide comment
@ccmtaylor

ccmtaylor Aug 26, 2016

we use <<= a lot to setup assembly settings like

assemblyMergeStrategy in assembly <<= (assemblyMergeStrategy in assembly) { (old) => {
        case PathList("org", "mockito", xs @ _*) => MergeStrategy.first
        case PathList("com", "twitter", "common", xs @ _*) => MergeStrategy.first
        case x => old(x)
      }}

Intellij throws a fit trying to parse it, but it works :)

we use <<= a lot to setup assembly settings like

assemblyMergeStrategy in assembly <<= (assemblyMergeStrategy in assembly) { (old) => {
        case PathList("org", "mockito", xs @ _*) => MergeStrategy.first
        case PathList("com", "twitter", "common", xs @ _*) => MergeStrategy.first
        case x => old(x)
      }}

Intellij throws a fit trying to parse it, but it works :)

@eed3si9n

This comment has been minimized.

Show comment
Hide comment
@eed3si9n

eed3si9n Aug 26, 2016

Member

@magro The RHS of <<= is an Initialize[_] expression. For instance the return type of dependsOn method is Initialize[Task[A]]. And, anything that returns Initialize[_] can be put in a parenthesis and then put .value at the end as follows:

compile in Jmh := ((compile in Jmh) dependsOn (compile in Test)).value
Member

eed3si9n commented Aug 26, 2016

@magro The RHS of <<= is an Initialize[_] expression. For instance the return type of dependsOn method is Initialize[Task[A]]. And, anything that returns Initialize[_] can be put in a parenthesis and then put .value at the end as follows:

compile in Jmh := ((compile in Jmh) dependsOn (compile in Test)).value
@magro

This comment has been minimized.

Show comment
Hide comment
@magro

magro Aug 26, 2016

@eed3si9n Awesome, thanks for the great explanation!

magro commented Aug 26, 2016

@eed3si9n Awesome, thanks for the great explanation!

@dwijnand

This comment has been minimized.

Show comment
Hide comment
@dwijnand

dwijnand Aug 26, 2016

Member

@ccmtaylor:

assemblyMergeStrategy in assembly ~= (old => {
  case PathList("org", "mockito", xs @ _*)           => MergeStrategy.first
  case PathList("com", "twitter", "common", xs @ _*) => MergeStrategy.first
  case x                                             => old(x)
})
Member

dwijnand commented Aug 26, 2016

@ccmtaylor:

assemblyMergeStrategy in assembly ~= (old => {
  case PathList("org", "mockito", xs @ _*)           => MergeStrategy.first
  case PathList("com", "twitter", "common", xs @ _*) => MergeStrategy.first
  case x                                             => old(x)
})
@SethTisue

This comment has been minimized.

Show comment
Hide comment
@SethTisue

SethTisue Aug 26, 2016

Contributor

the thing about <<= and dependsOn is going to be an FAQ for sure. I'd say it accounts for most of the old operator usages I still see in the wild

Contributor

SethTisue commented Aug 26, 2016

the thing about <<= and dependsOn is going to be an FAQ for sure. I'd say it accounts for most of the old operator usages I still see in the wild

@dwijnand

This comment has been minimized.

Show comment
Hide comment
@dwijnand

dwijnand Aug 26, 2016

Member

I've not had a chance to review this yet but ideally <<='s deprecation message could detail that.

Member

dwijnand commented Aug 26, 2016

I've not had a chance to review this yet but ideally <<='s deprecation message could detail that.

@eed3si9n eed3si9n changed the title from Remove old operators `<<=`, `<+=`, and `<++=` to [sbt 1.0] Remove old operators `<<=`, `<+=`, and `<++=` Aug 27, 2016

eed3si9n added a commit to eed3si9n/sbt that referenced this pull request Aug 27, 2016

Deprecate the old operators `<<=`, `<+=`, and `<++=`
The no-longer-documented operators `<<=`, `<+=`, and `<++=` are
deprecated, in anticipation of the removal in sbt 1.0. Ref #2711

For `<<=`, the suggested migration would be to use either `:=` or `~=`
operators. The RHS of `<<=` takes an `Initialize[_]` expression, which
can be converted to `:=` style by wrapping the expression in
parenthesis, and calling `.value` at the end.

eed3si9n added a commit to eed3si9n/sbt that referenced this pull request Aug 27, 2016

Deprecate the old operators `<<=`, `<+=`, and `<++=`
The no-longer-documented operators `<<=`, `<+=`, and `<++=` are
deprecated in anticipation of the removal in sbt 1.0. Ref #2711

For `<<=`, the suggested migration would be to use either `:=` or `~=`
operators. The RHS of `<<=` takes an `Initialize[_]` expression, which
can be converted to `:=` style by wrapping the expression in
parenthesis, and calling `.value` at the end.

eed3si9n added a commit to eed3si9n/sbt that referenced this pull request Aug 27, 2016

Deprecate the old operators `<<=`, `<+=`, and `<++=`
The no-longer-documented operators `<<=`, `<+=`, and `<++=` are
deprecated in anticipation of the removal in sbt 1.0. Ref #2711

For `<<=`, the suggested migration would be to use either `:=` or `~=`
operators. The RHS of `<<=` takes an `Initialize[_]` expression, which
can be converted to `:=` style by wrapping the expression in
parenthesis, and calling `.value` at the end.

eed3si9n added a commit to eed3si9n/sbt that referenced this pull request Aug 28, 2016

Deprecate the old operators `<<=`, `<+=`, and `<++=`
The no-longer-documented operators `<<=`, `<+=`, and `<++=` are
deprecated in anticipation of the removal in sbt 1.0. Ref #2711

For `<<=`, the suggested migration would be to use either `:=` or `~=`
operators. The RHS of `<<=` takes an `Initialize[_]` expression, which
can be converted to `:=` style by wrapping the expression in
parenthesis, and calling `.value` at the end.
@eed3si9n

This comment has been minimized.

Show comment
Hide comment
@eed3si9n

eed3si9n Aug 28, 2016

Member

@metasim suggested on twitter:

Would be great if legacy usage generated a build error with instructions on how to fix, a la "implicit not found" errors.

It might be a good idea to to this in 1.0, not just 0.13.13, so I might bring back those methods and define a macro that just aborts with an error message.

Member

eed3si9n commented Aug 28, 2016

@metasim suggested on twitter:

Would be great if legacy usage generated a build error with instructions on how to fix, a la "implicit not found" errors.

It might be a good idea to to this in 1.0, not just 0.13.13, so I might bring back those methods and define a macro that just aborts with an error message.

@magro

This comment has been minimized.

Show comment
Hide comment
@magro

magro Aug 28, 2016

A helpful error message would indeed be great!

magro commented Aug 28, 2016

A helpful error message would indeed be great!

@dwijnand

This comment has been minimized.

Show comment
Hide comment
@dwijnand

dwijnand Aug 28, 2016

Member

@eed3si9n Ideally for 1.0 we could do that in sbt-compat (ref #2660).

Member

dwijnand commented Aug 28, 2016

@eed3si9n Ideally for 1.0 we could do that in sbt-compat (ref #2660).

@eed3si9n

This comment has been minimized.

Show comment
Hide comment
@eed3si9n

eed3si9n Aug 28, 2016

Member

@dwijnand I was thinking sbt-compat would be more for sbt plugin authors to backport sbt 1.0 plugins so it's source-compatible with sbt 0.13 if it's possible. Any migration error message if we're adding them should be added to sbt out of the box without additional plugin if we're targeting build users, no?

Member

eed3si9n commented Aug 28, 2016

@dwijnand I was thinking sbt-compat would be more for sbt plugin authors to backport sbt 1.0 plugins so it's source-compatible with sbt 0.13 if it's possible. Any migration error message if we're adding them should be added to sbt out of the box without additional plugin if we're targeting build users, no?

@dwijnand

This comment has been minimized.

Show comment
Hide comment
@dwijnand

dwijnand Aug 29, 2016

Member

Ah I see, yes.

Personally I think we should deprecate in 0.13 and remove in 1.0: they've
been "socially" deprecated for a while now.

On Mon, 29 Aug 2016, 01:21 eugene yokota, notifications@github.com wrote:

@dwijnand https://github.com/dwijnand I was thinking sbt-compat would
be more for sbt plugin authors to backport sbt 1.0 plugins so it's
source-compatible with sbt 0.13 if it's possible. Any migration error
message if we're adding them should be added to sbt out of the box without
additional plugin if we're targeting build users, no?


You are receiving this because you were mentioned.

Reply to this email directly, view it on GitHub
#2711 (comment), or mute
the thread
https://github.com/notifications/unsubscribe-auth/AAVCIuEqmzMsL0x-9nmxTXoYwvZQyeJ3ks5qkhf1gaJpZM4Jtumv
.

Member

dwijnand commented Aug 29, 2016

Ah I see, yes.

Personally I think we should deprecate in 0.13 and remove in 1.0: they've
been "socially" deprecated for a while now.

On Mon, 29 Aug 2016, 01:21 eugene yokota, notifications@github.com wrote:

@dwijnand https://github.com/dwijnand I was thinking sbt-compat would
be more for sbt plugin authors to backport sbt 1.0 plugins so it's
source-compatible with sbt 0.13 if it's possible. Any migration error
message if we're adding them should be added to sbt out of the box without
additional plugin if we're targeting build users, no?


You are receiving this because you were mentioned.

Reply to this email directly, view it on GitHub
#2711 (comment), or mute
the thread
https://github.com/notifications/unsubscribe-auth/AAVCIuEqmzMsL0x-9nmxTXoYwvZQyeJ3ks5qkhf1gaJpZM4Jtumv
.

dwijnand added a commit that referenced this pull request Aug 29, 2016

Deprecate the old operators `<<=`, `<+=`, and `<++=` (#2716)
* Backport style changes in tests and Defaults.scala

This backports the scripted tests and Defaults.scala style changes to
use `build.sbt` and `:=`.

* Fix backport

* 	Deprecate the old operators `<<=`, `<+=`, and `<++=`

The no-longer-documented operators `<<=`, `<+=`, and `<++=` are
deprecated in anticipation of the removal in sbt 1.0. Ref #2711

For `<<=`, the suggested migration would be to use either `:=` or `~=`
operators. The RHS of `<<=` takes an `Initialize[_]` expression, which
can be converted to `:=` style by wrapping the expression in
parenthesis, and calling `.value` at the end.
@eed3si9n

This comment has been minimized.

Show comment
Hide comment
@eed3si9n

eed3si9n Aug 29, 2016

Member

@dwijnand I don't know if we can count on all users first trying 0.13.13 before jumping to sbt 1.0 out of some necessity. I don't think it hurts to put def <<= with a macro backing that immediately fails with an error message.

Member

eed3si9n commented Aug 29, 2016

@dwijnand I don't know if we can count on all users first trying 0.13.13 before jumping to sbt 1.0 out of some necessity. I don't think it hurts to put def <<= with a macro backing that immediately fails with an error message.

@dwijnand

This comment has been minimized.

Show comment
Hide comment
@dwijnand

dwijnand Aug 29, 2016

Member

It's just extra cruft we have to hold on to.. When would you be happy to then actually get rid of them? sbt 2.0? or sbt 1.1?

Member

dwijnand commented Aug 29, 2016

It's just extra cruft we have to hold on to.. When would you be happy to then actually get rid of them? sbt 2.0? or sbt 1.1?

@metasim

This comment has been minimized.

Show comment
Hide comment
@metasim

metasim Aug 30, 2016

Member

It's just extra cruft we have to hold on to.. When would you be happy to then actually get rid of them? sbt 2.0? or sbt 1.1?

Given the potential to save people a lot of frustration, I'd say keep them until 2.0. That said, maybe implement them in a file called Cruft.scala just to make the point? :-)

Member

metasim commented Aug 30, 2016

It's just extra cruft we have to hold on to.. When would you be happy to then actually get rid of them? sbt 2.0? or sbt 1.1?

Given the potential to save people a lot of frustration, I'd say keep them until 2.0. That said, maybe implement them in a file called Cruft.scala just to make the point? :-)

@eed3si9n

This comment has been minimized.

Show comment
Hide comment
@eed3si9n

eed3si9n Aug 30, 2016

Member

I talked to Dale earlier, and he's cool with error message only macro idea.

Member

eed3si9n commented Aug 30, 2016

I talked to Dale earlier, and he's cool with error message only macro idea.

eed3si9n added some commits Aug 30, 2016

Replace the old operators with Restligeist macros
The old operators `<<=`, `<+=`, and `<++=` are now replaced with
Restligeist macros that will always fail during compile-time but can
display migration guide as the error message.

This would provide better upgrade experience than simply removing the
methods and displaying `<<= is not a member of sbt.TaskKey`.
@dwijnand

This comment has been minimized.

Show comment
Hide comment
@dwijnand

dwijnand Aug 30, 2016

Member

LGTM

Member

dwijnand commented Aug 30, 2016

LGTM

@dwijnand dwijnand merged commit 2df9f94 into sbt:1.0.x Aug 30, 2016

2 checks passed

codacy/pr Good work! A perfect pull request.
Details
continuous-integration/travis-ci/pr The Travis CI build passed
Details

@dwijnand dwijnand removed the in progress label Aug 30, 2016

@eed3si9n eed3si9n deleted the eed3si9n:wip/value_and_op branch Aug 30, 2016

@metasim

This comment has been minimized.

Show comment
Hide comment
@metasim

metasim Aug 30, 2016

Member

+1 for use of "Restligeist" :-)

Member

metasim commented Aug 30, 2016

+1 for use of "Restligeist" :-)

@eed3si9n

This comment has been minimized.

Show comment
Hide comment
@DavidPerezIngeniero

This comment has been minimized.

Show comment
Hide comment
@pfn

This comment has been minimized.

Show comment
Hide comment
@pfn

pfn Sep 12, 2016

Yuck, I use this mnemonic quite often

def someTask = Def.task {
... 
} 

someTaskKey <<= someTask

Changing it to someTaskKey := someTask.value feels so ugly. The change to dependsOn is especially ugly and a reason I exclusively use <<=

pfn commented Sep 12, 2016

Yuck, I use this mnemonic quite often

def someTask = Def.task {
... 
} 

someTaskKey <<= someTask

Changing it to someTaskKey := someTask.value feels so ugly. The change to dependsOn is especially ugly and a reason I exclusively use <<=

magro added a commit to magro/eventuate that referenced this pull request Nov 2, 2016

@magro magro referenced this pull request in RBMHTechnology/eventuate Nov 2, 2016

Merged

Revive build.properties, remove byte order mark #353

@eed3si9n eed3si9n referenced this pull request Nov 15, 2016

Closed

[sbt 1.0] Forward port 0.13 changes #2352

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