These are chat archives for sbt/sbt

1st
Jun 2017
Thomas Sutton
@thsutton
Jun 01 06:30
I have a build that uses a plugin. This plugin requires certain resources that some developers don't have access to. I'd like to modify the build to check for these resources (check some executable the plugin will use are present, etc.) and depend on and configure the plugin only when these resources are available on the current machine. Can anyone suggest how to do this? The closest I've come is a build that always depends on the plugin and just wraps if around every single mention of it's settings, etc. in build.sbt.
Dale Wijnand
@dwijnand
Jun 01 07:00
Try making the definition of trigger conditional to this external state.
@dwijnand does that make sense?
let's suppose you need docker installed on the machine to be the precondition
would one define a plugin IHaveDockerPlugin?
Jorge
@jvican
Jun 01 07:40
ResourceInspector?
I think it makes sense to me to embed this logic into preconditions of trigger. I have actually never thought about it, but to me it seems an elegant solution.
eugene yokota
@eed3si9n
Jun 01 07:42
suppose FooPlugin requires docker but @thsutton doesn't have access to the FooPlugin's source code
Jorge
@jvican
Jun 01 07:42
But i wouldn't create a plugin only for this. I would try to extend the preconditoin to embed the logic to check if the environment is ok.
eugene yokota
@eed3si9n
Jun 01 07:43
trigger says if I have plugin X (e.g. JvmPlugin), enable Y (e.g. PgpPlugin)
if you need to conditionally include a plugin I think you'd need to do it at enablePlugins clause, but I don't know if that's pretty
I've proposed build level before related to these situations - https://github.com/sbt/sbt/wiki/User-Stories:-Build-Level
jaksky
@jaksky
Jun 01 13:41
How to specify that one task has to be done before another one in single project? How chain existing one from the same phase Compile
jaksky
@jaksky
Jun 01 13:58
I would like to specify the order in which the source generators are run
Was trying as follows: sourceGenerators in Compile := Def.sequential(PB.generate ,buildInfo )
Jorge
@jvican
Jun 01 14:13
You cannot do that (in an easy way) @jaksky
Why do you need to do that?
jaksky
@jaksky
Jun 01 16:04
@jvican The issue there is that one task is deleting source generated by the second one. I want those to be addition so If I guarantee the ordering that would help
Protobuf generator cleans managed sources where the build info already generated classes
@jvican What would be the correct way of doing that?
Justin Kaeser
@jastice
Jun 01 16:29
maybe you can redefine one generator task to depend on another, no idea if it will work out for generators ...
jaksky
@jaksky
Jun 01 16:53
Was trying that as well
But wasn┬Ęt able to make it work
PB.generate in Compile := {
  val res = PB.generate.value
  buildInfo.value
  res
}
OlegYch
@OlegYch
Jun 01 16:57
override targets to use sourceManaged.value / "protobuf"
Jorge
@jvican
Jun 01 20:19
I would do it @jastice's way
By using either triggeredBy or dependsOn
Martin Duhem
@Duhemm
Jun 01 21:13
Has anyone ever experienced issues with sbt new and .travis.yml? I'm getting the following error when running sbt new scala-native/scala-native.g8: (That's with sbt 0.13.15)
Exiting due to error in the template
File: /var/folders/2t/w19h5hlj3771d27wmmcr8m480000gn/T/giter8-113086732528454/.travis.yml, 54:0: 'script' came as a complete surprise to me
Jorge
@jvican
Jun 01 21:49
@jastice What should we do to get support for sbt 1.0 in Intellij?
Justin Kaeser
@jastice
Jun 01 21:56
@jvican wait til next week is the easy option for you
Jorge
@jvican
Jun 01 21:57
will do that then :)
Justin Kaeser
@jastice
Jun 01 21:57
or if you want it now, build scala plugin yourself. it seems to work but broke a number of tests, so it's not merged yet
btw is the lockfile stuff in 1.0 and if yes where and how is it implemented?
Jorge
@jvican
Jun 01 22:00
the lock file is not yet finished, but it's very close to reach its end of implementation time
i'm planning to release a binary-compatible Scala Center sbt version with it for the early adopters
Justin Kaeser
@jastice
Jun 01 22:01
implementing my own locking right now :D
Jorge
@jvican
Jun 01 22:01
will keep you in the loop for that
Justin Kaeser
@jastice
Jun 01 22:01
was just wondering how you're doing yours
Jorge
@jvican
Jun 01 22:01
how so? i suggest you wait for mine :D
Justin Kaeser
@jastice
Jun 01 22:01
no, for libling
so it's different
Jorge
@jvican
Jun 01 22:02
too much duplication of effort
oh, what's the use case? don't quite see it
Justin Kaeser
@jastice
Jun 01 22:02
having a simple way to deploy and depend on bits of sources
I think we've talked about it before
also it's an experiment in rethinking versioning
Jorge
@jvican
Jun 01 22:04
i've also wanted to play with that
i think git-based versions are the way to go, for everything
Justin Kaeser
@jastice
Jun 01 22:05
you're invited!
Jorge
@jvican
Jun 01 22:05
the cool thing is that you can get these versions from the sources and generate the artifacts from scratch
i may join you when i find sometime @jastice :D I'm back to work these days, sbt + zinc
Justin Kaeser
@jastice
Jun 01 22:06
still kind of need to figure out some details on how to combine hard hashes with friendly tags and numbers and distributed repo setups
Jorge
@jvican
Jun 01 22:10
what semantics do you want the version number to have?
Justin Kaeser
@jastice
Jun 01 22:13
ideally I want to be at a point where I define a set of commits as compatible in some sense, and have an index of those, so that automatic upgrades can be done within this set
those sets might technically even overlap, dunno
then probably a transition graph between the sets that tells you recommended upgrade paths
usually they'd be linear with an occasional fork
Jorge
@jvican
Jun 01 22:18
why commits and not assume that all the changes in a concrete VCS branch will be binary compatible?
Justin Kaeser
@jastice
Jun 01 22:19
how could I assume that? commits break stuff all the time
keeping it real, you'd want to tag certain commits as "safe", aka a release version
Jorge
@jvican
Jun 01 22:20
usually, development in a repo is organized
you always have invariants and conventions
i think these invariants end up being good coding practices
one of those is the fact that you may want to use branches to organize your work
scalac does ensure bincompat on every commit in a branch
Justin Kaeser
@jastice
Jun 01 22:21
even if you have good branching practices you'll have lots of regressions
Jorge
@jvican
Jun 01 22:21
well, no if you use MiMa :D
Justin Kaeser
@jastice
Jun 01 22:21
they might be subtle
Jorge
@jvican
Jun 01 22:22
yes, but then, I ask you: how are you so sure a given commit is safe to migrate to?
it may subtly introduce binary incompatible changes
Justin Kaeser
@jastice
Jun 01 22:23
I'm not, can only approximate
Jorge
@jvican
Jun 01 22:23
same argument for branches :D
Justin Kaeser
@jastice
Jun 01 22:23
right
Jorge
@jvican
Jun 01 22:23
my point is, you may want to simplify it by just assuming all changes in a branch are bincompat
and then use that for the versioning
Ryan Williams
@ryan-williams
Jun 01 22:24
what projects are y'all working on that are related to solving these problems? i'm very interested in the "simple way to deploy and depend on bits of sources" and "get these versions from the sources and generate the artifacts from scratch" bits :)
Jorge
@jvican
Jun 01 22:25
i'm working on sbt/scalac/zinc, but i'm interested in the solution to these problems because i'd like to bring some of the tooling of projects in big corps (twitter, google, et cetera) to sbt
we're discussing about best development practices, essentially
i'm a firm believer of source dependencies, but to make them work you need good infrastructure
caching of compilation for every commit, for example
Justin Kaeser
@jastice
Jun 01 22:27
so I can of course choose to depend on repo X's master branch all the time under the assumption all changes in there are bincompat
Jorge
@jvican
Jun 01 22:28
you're trying to solve a tricky problem
Justin Kaeser
@jastice
Jun 01 22:28
and re-resolve the most current commit and update my lockfile
Jorge
@jvican
Jun 01 22:28
yeah
well, it's curious how the current sbt solves this problem
you can specify the commit hash of a source dependency, and sbt will get check it out
Justin Kaeser
@jastice
Jun 01 22:29
yeah
Jorge
@jvican
Jun 01 22:29
that's the "version" of your source dependency
Justin Kaeser
@jastice
Jun 01 22:29
or you don't specify and get whatever is the head and it never updates
Jorge
@jvican
Jun 01 22:29
IMO, reasoning about safe migrations based on commits is difficult, it should be left to the user
Justin Kaeser
@jastice
Jun 01 22:30
it's not my initial focus
but ultimately a thing that needs better solutions
major.minor.fix versioning is a hack, I tell ya
also I
I'm not sure what to do about binary deps of source deps. for now I'm forbidding them, except for scala stdlib
Justin Kaeser
@jastice
Jun 01 22:38
anyway, I just wanted to know what's in your lockfile, @jvican
Jorge
@jvican
Jun 01 22:38
will reply to you tomorrow :)
scaladays killed me today
gonna hit bed, take care Justin!
Justin Kaeser
@jastice
Jun 01 22:39
sleep tight