These are chat archives for sbt/sbt

1st
Mar 2015
Sam Halliday
@fommil
Mar 01 2015 00:18
@jsuereth you think that more modular is going to bring people to contribute? The SBT project structure is already incredibly complicated. I would have thought reconciling would be more likely to help here.
I get lost everytime I need to look in the sbt source for anything. It'd be hell of a lot easier to navigate if it was just: compiler interface / compiler core / sbt
I had assumed that sbt itself was a showcase for a multi-module project, rather than it being out of necessity
@eed3si9n +1 for stability and performance. The improved resolution stuff dwarves anything else on the roadmap
it's never a good sign when IntelliJ users (curious about how the "official" build of the project works) drop down to sbt and have to watch files be resolved for 10 minutes when they know the files are already in the ivy cache.
Sam Halliday
@fommil
Mar 01 2015 00:23
then they type "exit" and have to do it all again
Josh Suereth
@jsuereth
Mar 01 2015 00:30
modularizing would also involve simplifying/unifying
Josh Suereth
@jsuereth
Mar 01 2015 00:35
additionally, curious what you find complicated. The incremental compiler itself is fragmented up a bit, but a lot of the rest is pretty well modularized (IO, completion, logging, collections, tasks)
Havoc Pennington
@havocp
Mar 01 2015 01:14
the sbt source has a lot of fairly "surface"/"incidental" complexity when you're trying to find something, caused by things like import foo._, blah instead of import foo, foo.blah, type aliases, use of invisible method names like apply(), lack of comments, stuff like that. I think modularity will be helpful myself but the difficulty of the codebase for me is mostly that it's just a little too far on the "don't write things out explicitly" side of the fence. but then, I usually prefer verbose code. and verbose english.
Josh Suereth
@jsuereth
Mar 01 2015 01:17

right, so modularity doesn't help/hurt that aspect. It's orthogonal.

Still, I plan to cleanup, comment, etc. as we pull out modules. E.g. sbt/launcher is getting close to being ok on its own (see https://github.com/sbt/launcher). First step was documenting all the public APIs

eugene yokota
@eed3si9n
Mar 01 2015 02:25
one aspect of modularity (as in multiple repo + multiple version mix) that's worrisome is what happens to the ability to tie a particular piece of class back to source code location in Github. it's already very hard to do so with sbt, but we can at least use grep if it's all under sbt/sbt.
once things are under multiple repos, should we start making packages for them, and maybe sbt package object aliases?
Havoc Pennington
@havocp
Mar 01 2015 02:27
I think it'd be helpful if there were a lot more sub packages under sbt. , but obviously creates a big back compat headache
eugene yokota
@eed3si9n
Mar 01 2015 02:28
Java's one class one file convention is restrictive, but makes it easier when you're hacking on other people's project
package object aliases can alleviate the pain (hopefully) on sbt.IO located under sbt.io.IO or something
Havoc Pennington
@havocp
Mar 01 2015 02:28
right. more packages would only help if one package = one source dir in one repo
Josh Suereth
@jsuereth
Mar 01 2015 02:30
Personally I'd like to just see more packages so it's apparent....
eugene yokota
@eed3si9n
Mar 01 2015 02:30
we need some strong convention otherwise we'd end up with 10 x 10 problem
like sbt.io.Network located under sbt/util or some such
Josh Suereth
@jsuereth
Mar 01 2015 02:34
Yeah. Convention should be sbt.x.... => sbt/x
Where sub packages should be under that module too
eugene yokota
@eed3si9n
Mar 01 2015 02:35
you say that now. but we'll be tempted into all the private evil stuff
the ideal world is that we have impl-less API JAR so API compat is enforced by type
Josh Suereth
@jsuereth
Mar 01 2015 02:38
Right and impl packages under sbt.x
eugene yokota
@eed3si9n
Mar 01 2015 02:38
I need :coffee: and :donut:
Dale Wijnand
@dwijnand
Mar 01 2015 08:31
Talking about history what's Mark Harrah up to these days?
eugene yokota
@eed3si9n
Mar 01 2015 08:32
we saw him at nescala
I sometimes send sbt-dev messages just so he gets it, since he doesn't use twitter
Dale Wijnand
@dwijnand
Mar 01 2015 08:33
has he left Typesafe?
eugene yokota
@eed3si9n
Mar 01 2015 08:34
yes. but I prefer not talking about others without their presence
Dale Wijnand
@dwijnand
Mar 01 2015 08:35
sure
Sam Halliday
@fommil
Mar 01 2015 09:44
re modules, I think you said everything I wanted to say. Modularising only makes it easier if the modules are standalone projects. Right now, I look at the module structure and it just looks arbitrary to me. More modules make it really hard to browse source on github so they should only be for truly separated things. In ENSIME we go for: public API, (choice of protocol), server
and server has a done of stuff in there that is technically independent, but actually since the end goal is to provide the ensime-server, there is no point in splitting it up. Likewise, with sbt, I don't see value in splitting it up beyond public api / compiler / sbt core
Josh Suereth
@jsuereth
Mar 01 2015 14:14
Right. Most of our modules will be things we already use in more than one location. sbt.IO and sbt-completion are good examples I've seen used in a few non-sbt specific settings
Sam Halliday
@fommil
Mar 01 2015 15:10
is there really a lot of value in somebody using sbt.IO but not having a few other sbt-related classes on their classpath too? We're living in a world where the resolution and network lag overhead to download 5 50k jars is much higher than a single 1MB jar.
i.e. optimising how much stuff is in a jar is a non-issue, and there are tools to reduce jar bloat for the situations that call for it
Josh Suereth
@jsuereth
Mar 01 2015 15:12
Yes, we believe there is value
and we already have to do it
we're just formalizing
(if you notice, sbt-io, sbt-completion are already released cross-versioned as libraries)
Sam Halliday
@fommil
Mar 01 2015 15:13
would you ever considering moving the sbt.IO into a general utility library like https://github.com/stacycurl/pimpathon ?
that way there is no confusion at all
or release the completion library with its own name: again to avoid confusion about "this is/isn't sbt"
"stabby" :-P
(there's a Futurama character that might be relevant here...)
Josh Suereth
@jsuereth
Mar 01 2015 15:20
Yeah. It may be under our org, but it'll just be called completion.
Also, changing branding would need a purpose. I'd rather people just find sbt libs as a corpus of handy libraries, similar to like an apache commons
Sam Halliday
@fommil
Mar 01 2015 15:26
ok, if that's the approach. Personally, I find that confusing because I see SBT as the build tool, and ZINC as an incremental compiler, not a commons... but of course the reality is much more complicated.
is there a typesafe commons?
Josh Suereth
@jsuereth
Mar 01 2015 15:33
No. However zinc on its own is useless. It's still a question of whether or not we pull the real incremental compiler out and have zinc be that instead of what it is now
To do that, you'd need libraries which do what sbt fors for io, or make that part of zinc. Right now it all gets james in both places via a weird build path. I'd like to correct that.
Sam Halliday
@fommil
Mar 01 2015 15:35
+1 to pulling out. I had to go through the joy of building zinc on 2.11 recently
so, yes, I understand the weird build path all too well
I was quite surprised that it, ultimately, just pulled in a fat jar of sbt
(which, TBH, made the claim that "maker is a replacement for sbt" pretty laughable)