These are chat archives for sbt/sbt

25th
Nov 2015
wedens
@wedens
Nov 25 2015 05:49
when I do inConfig(Distrib)(Defaults.compileSettings ++ Classpaths.ivyPublishSettings ++ Classpaths.jvmPublishSettings ++ Classpaths.ivyBaseSettings) what it does?
why do I need to "copy" this if it is default?
how do I know what I need to "copy"?
Perry
@pfn
Nov 25 2015 05:55
because you want distrib:foo to do something
it's empty otherwise
wedens
@wedens
Nov 25 2015 05:56
ok. can I say "do the same things as default configuration"?
Perry
@pfn
Nov 25 2015 06:09
nope
wedens
@wedens
Nov 25 2015 06:14
but why? I expect it to work as some kind of profile
derived from some other profile
so, in sbt there is no abstraction for it?
and using config as profile is just abuse? :)
Perry
@pfn
Nov 25 2015 15:44
pretty much
hmm, I hate blowing away .ivy/cache
makes my life miserable waiting for the internet to download
(had to blow away because I screwed it over by trying to merge cache from another machine)
Erik LaBianca
@easel
Nov 25 2015 16:24
run a local copy of artifactory =p
Josh Suereth
@jsuereth
Nov 25 2015 16:24
that's what I wound up doing
it's sad though
I even hacked my way through Aether to see if I could improve it
unfortuantely, SO much of sbt is tied to Ivy Configuration model, breaking out of that is hard
AND ivy itself is not designed well for caching
Erik LaBianca
@easel
Nov 25 2015 16:31
yeah ivy seems to be remarkably crufty, it seems like if https://github.com/alexarchambault/coursier were mature enough to use it could really help clean up sbt
Perry
@pfn
Nov 25 2015 17:39
yeah, I'm not going to run a local artifactory for this case
trying to see if I can modify patterns to do what I want
and just add it as another resolver
Perry
@pfn
Nov 25 2015 18:14
ugh, localBasePattern isn't good for ivy/cache
it's for ivy/local
Perry
@pfn
Nov 25 2015 18:26
val cacheRepository = {
  val pat1 = "[organisation]/[module]/[type]s/[artifact](-[classifier])-[revision].[ext]"
  val pat2 = "[organisation]/[module]/[artifact](-[classifier])-[revision].[ext]"
  val pList = ("${ivy.home}/extra-cache/" + pat1) ::
    ("${ivy.home}/extra-cache/" + pat2) :: Nil
  FileRepository("extra-cache", Resolver.defaultFileConfiguration, Patterns(pList, pList, false))
}
this seems to do what I want
and of course, resolvers += cacheRepository
Perry
@pfn
Nov 25 2015 18:34
the ${ivy.home} isn't necessary, I suppose
(could move it outside of ivy.home)
InTheNow
@InTheNow
Nov 25 2015 19:16
Is this the right channel for dbuild questions?
And specifically, the use of ProjMeta
InTheNow
@InTheNow
Nov 25 2015 19:21
A google of "dbuild ProjMeta" yields 4 results, most unusual.
Perry
@pfn
Nov 25 2015 20:09
wow, gradle caching is so garbage, it's path sensitive... (then again, ivy has a slightly similar issue)
no idea what dbuild is
pfn @pfn shrugs
Seth Tisue
@SethTisue
Nov 25 2015 21:32
@InTheNow this is as good a place as any for dbuild questions
Sam Halliday
@fommil
Nov 25 2015 23:39
@dwijnand (moving room) the test case in sbt/sbt#2266 also applies for sbt/sbt#2270
I'm pretty sure the hack I describe in 2270 would fix almost everything I'm facing, but I have no idea how to implement it
Dale Wijnand
@dwijnand
Nov 25 2015 23:43
If you're interested in fixing it you could ask in sbt/sbt-dev
I personally have never looked at that area and didn't even know of exportJar
Sam Halliday
@fommil
Nov 25 2015 23:45
@dwijnand ok, I was hoping you'd know. I'm actually too busy to look into it so I've flagged it up as something that typesafe should be fixing for us through our support contract.
I expect a fix in about 2017
(it takes about half that long for our tickets to get raised to them)
Dale Wijnand
@dwijnand
Nov 25 2015 23:46
Meanwhile you can work on break that project up into saner chunks :P
Sam Halliday
@fommil
Nov 25 2015 23:46
LOL
ROTFL
400 developers, 20 release branches, I'm sure they'd enjoy me doing that :-)
Dale Wijnand
@dwijnand
Nov 25 2015 23:47
from where I'm sitting 1 minute to check all's good across 100 subprojects worth of source code is "instant"
Sam Halliday
@fommil
Nov 25 2015 23:47
on that example?
maybe its a windows thing
Dale Wijnand
@dwijnand
Nov 25 2015 23:47
oh god
ok wager that war first
Sam Halliday
@fommil
Nov 25 2015 23:48
it's a lot of code
I understand it is the largest scala codebase on the planet, by an order of magnitude
and when I type "module/compile" near the top of the dependency tree, I just see it spit out messages about missing main classes in the jars for about a minute, and then it decides there is nothing to compile
I really want it to just say "ok, all the jars are there... let get on with compiling this module..."
but I have absolutely no idea how to implement that. We have a build pipeline in place, so we can use our own custom sbt if needed, but that's a last resort (and I have absolutely no idea how to implement the hack... even where to look for what is happening when I type compile)
... and then it enters the incremental compiler and I've never looked in there
and apparently the incremental compiler is the largest individual part of sbt
which is kind of why we're breaking up sbt into modules
as we have this thing that adds incremental compilation to scalac, but it's wrapped up also being a piece of a build tool
Sam Halliday
@fommil
Nov 25 2015 23:56
Aside: I wish it wasn't being broken up, it really slows down startup time (resolution) and complicates the distribution. Can't most of the modularisation just be done by putting things into different packages in the same project?
thanks for pointing out where this happesn, I may get impatient and look into this myself
I think the slowness is happening before the incremental compiler is called
because I'm sure the incremental compiler isn't inspecting all the dependency jars to see if they are up to date, right?
Matthew de Detrich
@mdedetrich
Nov 25 2015 23:58
It might if they are SNAPSHOT's
Sam Halliday
@fommil
Nov 25 2015 23:58
there has to be a point where sbt says "ok, I've constructed the classpath that the compiler needs... go"
@mdedetrich they aren't, but why would the compiler be doing that? Surely that's a concern of the build tool
Matthew de Detrich
@mdedetrich
Nov 25 2015 23:59
I think the distinction between the two are less clear in SBT land
Sam Halliday
@fommil
Nov 25 2015 23:59
uuugh
well, I can't see anything obvious in compileTask that is scanning the dependencies