These are chat archives for sbt/sbt

18th
Oct 2015
Pathikrit Bhowmick
@pathikrit
Oct 18 2015 07:42
how do i tell sbt to run a main in the test of a subproject? I tried this sbt "$subProjectName:test:run-main com.foo.Main"
but if i jump into sbt console and do project $subProjectName and then i do test:run-main com.foo.Main, it works
Perry
@pfn
Oct 18 2015 08:09
@pathikrit, subproject/test:run-main
matanster
@matanster
Oct 18 2015 10:28
Is there some orderly way to avoid a dependency being added to the classpath of its dependent project, so that the dependent project may opt to use its artifact from the local ivy repository? I'm dealing with a project hierarchy that includes sbt plugins and compiler plugins so this is just a thought.
If the classes are both supplied on the classpath and fetched by the dependent project as a library dependency, wouldn't that open up room for non-deterministic behavior?
To clarify - my question applies to both plugins (sbt, compiler) and libraries, all of which my hierarchy of projects involves.
Perry
@pfn
Oct 18 2015 13:23
@matanster, "provided"
matanster
@matanster
Oct 18 2015 13:46
Yeah, I thought about it. Not sure though it would not conflict with something when building plugins. I'll check it out. You mean that this should avoid the library dependency resolution right?

I'm stumped at something more basic though, working on putting my projects into a master build. The documentation has what I'd call almost a footnote, saying:

You cannot have a project subdirectory or project/*.scala files in the sub-projects. foo/project/Build.scala would be ignored

Does that mean, that when aggregating formerly separate projects into a single build definition, I must migrate all sbt scala code to the top level project?!?
Perry
@pfn
Oct 18 2015 14:23
yes
that's why you should favor build.sbt
@matanster, ^^
matanster
@matanster
Oct 18 2015 14:24
Wasn't the scala format supposed to supersede the .sbt one?
Eventually I mean..
Dale Wijnand
@dwijnand
Oct 18 2015 14:27
Nope, other way round
matanster
@matanster
Oct 18 2015 14:32
Gee
Is there any IDE support for working with .sbt files like one gets writing sbt build definitions in scala?
Dale Wijnand
@dwijnand
Oct 18 2015 14:33
Intellij
Srepfler Srdan
@schrepfler
Oct 18 2015 14:39

@pfn so, I've tried your suggestion

def adaptFiles(files: Seq[File]): scala.Seq[Attributed[File]] = {
  val res = for (file <- files) yield Attributed.blank(file)
  println(res)
  res
}

mappings in Universal ++= fromClasspath(adaptFiles((update.value.matching(artifactFilter(`type` = "zip")))), target = "libs", includeArtifact => includeArtifact.`type` == "jar", includeOnNoArtifact = false)

but as in the console I get ArraySeq() I think the update.value.matching does not match properly, can it be it's not there either?

matanster
@matanster
Oct 18 2015 14:40
@dwijnand In .scala files you could also jump to definition in IntelliJ, I hope that's the same with the .sbt strain of it.
I'm really baffled by it though. With scala files you can be organized, divide your build definition into objects and classes. Why is this going to be abandoned?
Can the .sbt files contain general scala code? They are still compiled aren't they?
Srepfler Srdan
@schrepfler
Oct 18 2015 14:47
ok, I think I understand what's the catch
I think if I create the Attributed by using blank(file)
it does not have any type data to match on
in the artefactFilter
I can definitely see the artefact if I filter by artifactFilter(name = "*")
Perry
@pfn
Oct 18 2015 15:02
@matanster, intellij has full completion and inspection support for sbt files
@schrepfler, no, do not use fromClasspath
Dale Wijnand
@dwijnand
Oct 18 2015 15:02
@matanster Scala files arent abandoned, its the Build trait that is
Perry
@pfn
Oct 18 2015 15:03
@schrepfler, I gave you the correct answer already yesterday, just add that update.value line directly to mappings
Perry
@pfn
Oct 18 2015 15:14
mappings ++= update.value.matching(...).flatMap(f => PathFinder(f) pair rebase(f.getParentFile, "where to go"))
typing this out on mobile sucks
@matanster, sbt files can contain most scala syntax, just can't define objects, classes and traits
matanster
@matanster
Oct 18 2015 15:17
It sounds like we'll need to stick to both .scala and .sbt files then, if people are to really take exploit of what sbt can do (I mean how far can one get without classes...)
As an aside sounds like some crazy AST manipulation for making .sbt files compile with scalac yet disallow classes and types definition :sparkles:
What seems to have driven such a design for sbt usage?
Perry
@pfn
Oct 18 2015 15:20
dsl
you generally don't need objects, classes and traits in build definitions
so, very far
if you do, it should go in a plugin
pfn @pfn absolutely hates when people split their build def over multiple files
Perry
@pfn
Oct 18 2015 15:27
makes understanding a build impossible without wasting time or importing into ide
matanster
@matanster
Oct 18 2015 15:27
Good to see we're on the same page about the value of efficiency and making others understand what you've done :+1:
So, we'll keep having .scala for those who use sbt as a task management tool outside the domain of builds, and just for no special reason?
matanster
@matanster
Oct 18 2015 15:33
Or if they are going away in 1.0, what has actually been so painful about them. What has driven this design? was it just so that there'd be no wrapper objects? that's all?
Srepfler Srdan
@schrepfler
Oct 18 2015 15:49
@pfn , that worked!
Srepfler Srdan
@schrepfler
Oct 18 2015 16:04
I've added the matcher and then it was easy
mappings in Universal ++= update.value.matching(artifactFilter(name = "nameoflib*", extension = "zip")).flatMap(f => PathFinder(f) pair rebase(f.getParentFile, "lib"))
is there some way that I also change the name of the file as well, currently the version is part of the file name
nameoflib-version.zip
Perry
@pfn
Oct 18 2015 16:14
@matanster, no, scala files should remain for the general development case, eg, migration from a misguided build into a plugin
@schrepfler, look at the type of mapping, you can change the rhs
matanster
@matanster
Oct 18 2015 16:34
@pfn Why leave opening for misguided abuse to begin with?
Are you sure about this? isn't it motivated by backward compatiblity?
Are you sure this is in any way the recommended way forward? I have not seen anything official nor a deprecation warning. What's been the key motivation for this change? maybe this is more for the \dev channel as I find it very much key for guiding my choices.
matanster
@matanster
Oct 18 2015 16:39
Maybe I have missed public notices about this - how shall I call it - quasi standardization around .sbt files. Most I read seemed to imply the other way around.
Perry
@pfn
Oct 18 2015 16:56
all public documentation points at using sbt files
scala files are basically for power usage
Srepfler Srdan
@schrepfler
Oct 18 2015 17:21
Rhs after pair or before that?
Srepfler Srdan
@schrepfler
Oct 18 2015 19:09
did it!
mappings in Universal ++= update.value.matching(artifactFilter(name = "mylib*", extension = "zip")).flatMap(f => PathFinder(f) pair rebase(f.getParentFile, "lib")) map { case (file, path) => file -> path.replaceAll(s"mylib-zip-${versions.mylibZip}.zip", "mylib.zip") }
thanks @pfn
matanster
@matanster
Oct 18 2015 19:51
@pfn thanks
matanster
@matanster
Oct 18 2015 19:56
@schrepfler so this code takes care of fetching a zip file packaged as a library dependency and placing it in a given directory in the project?
care to share what has been your use case for this?
Srepfler Srdan
@schrepfler
Oct 18 2015 19:57
yup, I'm using the sbt-native-packager and only jar's were finishing in the lib directory
so thanks to @pfn we started exploring what update gives us back, filtered it and then rebased the files (as they are in the ivy reactor) to the lib directory and then rename it to what I want it to be (so that I can always reference a known file name).
the files on the remote repo have a name which contains a version mylib-zip-1234.zip
matanster
@matanster
Oct 18 2015 20:06
Thanks, very interesting!
dazito
@dazito
Oct 18 2015 21:40
hey guys, every time I create a Play project with typesafe activator and I import that project to IntelliJ I get a message: "SBT compilation for play framework 2.x disabled by default".
any help would be appreciated :)