Move graph processing into a zero dependency library

[johnynek]

I want to use this code internally in scalding. Seems like the easiest way to get it done.

This is an interesting case, because all uses of it should probably be private. It would be great if somehow we could shade such dependencies (private dependencies should be a thing: can only use them from private or package private methods).

[johnynek]

note I also sorted two lists in Build.scala.

[johnynek]

an alternate approach would be to copy the code to scalding, and then have each use a source copy (in their own package names). This would not freeze either scalding or summingbird to depend on one version. That or put it in a separate repo that can be published as often as needed (kind of a pain at Twitter since making new repos requires approval).

[ianoc]

I think twin source for now makes the most sense with eventually being a
standalone project in one or a 3rd repo. You can iterate quickly as you
work more in scalding that way. Unless that seems like it's unlikely ?

On Friday, April 3, 2015, P. Oscar Boykin notifications@github.com wrote:

an alternate approach would be to copy the code to scalding, and then have
each use a source copy (in their own package names). This would not freeze
either scalding or summingbird to depend on one version. That or put it in
a separate repo that can be published as often as needed (kind of a pain at
Twitter since making new repos requires approval).

—
Reply to this email directly or view it on GitHub
#614 (comment).

[johnynek]

@ianoc yes, I think copying the source for now into scalding is probably fine (I don't want to break the DAG and have scalding depend on any part of this repo). That said, we should probably still merge this so we don't start sneaking dependencies into the graph code.

[CLAassistant]

All committers have signed the CLA.