scala-steward
scala-steward copied to clipboard
scala-steward-org
sbt-lock integration
Does steward work well on projects which utilize sbt-lock?
if not, what would it take to add support for it?
I've never used sbt-lock myself. Could you explain what you mean by adding support for it? What should Scala Steward do or not do if a project is using sbt-lock?
one option would be to run ; unlock; reload; lock (and possibly scalafmtSbt if scalafmt is being used in the project) in sbt, after it updates the version of the package -- that would propagate the new version of the package to the lock file.
another option would be to change the version of the package directly in the lock file, but that might be more complicated than the above.
does that make sense? (are you familiar with the concept of a version lock file, like in F# paket, Rust cargo, JavaScript yarn or Ruby Gemfile?)
Can the lockfile be updated with ; unlock; reload; lock (or something else) after the version has already been updated? If yes, we could add a PostUpdateHook that does this and is executed on every update when the project depends on sbt-lock. We would need to modify PostUpdateHook a little bit so that groupId and artifactId are made optional and the hook can be used for all updates. The enabledByCache field of this hook would then look if for sbt-lock in the dependencies of the project.
Can the lockfile be updated with ; unlock; reload; lock (or something else) after the version has already been updated?
I think that would work. Another alternative would be to run ; unlock; reload in a PreUpdateHoook (which does not exist?), and do a lock, in the PostUpdateHook
According to sbt-lock's README unlock just deletes the lockfile. The PostUpdateHook could do the same and then just run sbt lock and commit the changes to the lockfile. No need for a PreUpdateHook then.
Btw, what happens if sbt lock is called after the version bump is committed but not changed in the lockfile? Would it create the lockfile with updated versions or would sbt exit with an error because the lockfile is not up-to-date?
Btw, what happens if sbt lock is called after the version bump is committed but not changed in the lockfile? Would it create the lockfile with updated versions or would sbt exit with an error because the lockfile is not up-to-date?
it would create the lockfile normally. You would just see an warning in sbt stating that lock is not up to date...
it would create the lockfile normally. You would just see an warning in sbt stating that lock is not up to date...
Great. It sounds to me that a simple PostUpdateHook that just runs sbt lock after every update in projects that depend on sbt-lock would be enough then.
It sounds to me that a simple PostUpdateHook that just runs sbt lock after every update in projects that depend on sbt-lock would be enough then.
But how would the lock files be deleted? sbt unlock? manually? no one? If your idea was to just do a sbt lock after the "version bump" done by scala steward, then I think that would not work... You need to call unlock (or delete the locks)
PS: Another issue/feature that arises from using sbt-lock and scala-steward is that since the lockfile is just sbt code with dependencyOverrides ++= and all transitive dependencies are in this file, then all the transitive dependencies become direct dependencies in scala-steward's POV (I am not sure if this is still true, because scala-steward might have changed since last time I looked at this). That said I think is important to think about when would be the best time to call sbt unlock...
Scala Steward supports custom PostUpdateHooks in the repo config for a while now and I think sbt-lock integration can be purely done as PostUpdateHook. Anyone who wants to update their lock file after a version bump, can add an appropriate hook to their .scala-steward.conf file.