search

tkawachi / sbt-lock

Gemfile.lock for sbt
75 stars 12 forks source link

Improve workflow: Option to ignore lock.sbt dependencyOverrides when hash is stale #24

Closed htmldoug closed 5 years ago

htmldoug commented 5 years ago

Summary

Changes generation of lock.sbt files to produce something like:

// DON'T EDIT THIS FILE.
// This file is auto generated by sbt-lock 0.5.1-SNAPSHOT.
// https://github.com/tkawachi/sbt-lock/
dependencyOverrides ++= {
  if (!(sbtLockHashIsUpToDate in ThisBuild).value && sbtLockIgnoreOverridesOnStaleHash.value) {
    Set.empty
  } else {
    Set(
      "com.fasterxml.jackson.core" % "jackson-core" % "2.2.2"
    )
  }
}
// LIBRARY_DEPENDENCIES_HASH 7da3f2eacaf3740fecfd2bff3fb1679c8e37241e

Problem Background

The ingrained workflow with sbt is:

  1. change libraryDependencies
  2. > reload
  3. observe changes

I've introduced sbt-lock at work, but we're all getting tripped up by it regularly, which has halted adoption. Coworkers make libraryDependency changes which don't take effect because of lock.sbt, then they spend the next hour assuming the dependency is broken and looking upstream.

I think one contributing factor might that sbt handles dependency resolution automatically. There is no npm install step. You just edit libraryDependencies and you're generally good to go.

It's easy to forget that the repo they're making changes to is one of the few that use sbt-lock. The sbt console logging gets lost in the rest of the log spam noise. Requiring a behavior change is proving too difficult.

Proposed Solution

This PR adds a sbtLockIgnoreOverridesOnStaleHash := true key to allow libraryDependencies changes to take effect on reload, even without a ;unlock;reload;lock. We'll still enforce this in CI builds (e.g. require((sbtLockHashIsUpToDate in ThisBuild).value)), but local development workflow can remain the same way everyone's accustomed to.

I've set a default value of sbtLockIgnoreOverridesOnStaleHash := false to allow behavior to remain as it is today for existing consumers. We'll enable it in all our projects. If you think it's better to eliminate the complexity and just change the behavior, I'd be happy to do that too.

cc: @cake @jrouly @patrickjcurran @rcmurphy @arkban

htmldoug commented 5 years ago

I'm not sure why https://travis-ci.org/tkawachi/sbt-lock/jobs/465760029 failed. Both test and scripted pass locally. Has oraclejdk7 been removed from travis? I could use some help with that.

tkawachi commented 5 years ago

Hi, Thanks for the PR! I feel good about this approach. Please go ahead.

htmldoug commented 5 years ago

Okay, I'm done addressing my TODOs. Since last review:

Ready for another review.

htmldoug commented 5 years ago

@tkawachi thank you for the quick review, merge, and release. You're wonderful.