More Hashable discussion about algebird

[johnynek]

This code:

twitter/util#43

Was added to twitter util. That team works differently than we do, and they pull the code internally, and then eventually push it back to github.

I think that API will work, my only concern is "dependency hygiene". I don't want to pull all of twitter util just to get that one trait. I think util-hashing can be published as a jar without any external dependencies, and in that case I think we should consider using it (but they still haven't done that).

That said, it's only one trait and this project and scalding are much more active as open source projects (compare how many pull requests all of twitter-util has to algebird, which is much newer). So, maybe we are better off to copy-paste into a file here and if they get more open about pull requests, etc... use that code. We could even test the APIs here, and when they stabilize and look useful elsewhere we could push that code to util-hashing and depend on it then.

Avi has voiced a preference to avoid util-hashing (or so I thought), and Sam, I believe is in favor of using util-hashing.

What are your thoughts, Chris?

[sritchie]

My thought is that we try working with util, get the pull req in, then evaluate if the process worked. Don't make decisions based on fear and assumptions of incompetence.

Sam Ritchie
703.662.1337
@sritchie

On Saturday, December 22, 2012 at 12:11 AM, P. Oscar Boykin wrote:

This code:
twitter/util#43 (twitter/util#43)
Was added to twitter util. That team works differently than we do, and they pull the code internally, and then eventually push it back to github.
I think that API will work, my only concern is "dependency hygiene". I don't want to pull all of twitter util just to get that one trait. I think util-hashing can be published as a jar without any external dependencies, and in that case I think we should consider using it (but they still haven't done that).
That said, it's only one trait and this project and scalding are much more active as open source projects (compare how many pull requests all of twitter-util has to algebird, which is much newer). So, maybe we are better off to copy-paste into a file here and if they get more open about pull requests, etc... use that code. We could even test the APIs here, and when they stabilize and look useful elsewhere we could push that code to util-hashing and depend on it then.
Avi has voiced a preference to avoid util-hashing (or so I thought), and Sam, I believe is in favor of using util-hashing.
What are your thoughts, Chris?

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

[ccsevers]

I'm happy with util if you've already done the work. I just wasn't sure if anything had been done since the last update.

[avibryant]

I'll confirm that I'd rather not depend on util, because we've done so well avoiding heavy dependencies so far and I'm loathe to see the first one go in. But that's mostly an aesthetic rather than pragmatic position, so it's loosely held.

[sritchie]

It's a really light dependency, actually. Util-core is pretty small, and I think we can cut the dep on that. I'd like to give util a chance on util- hashing before we break out-- if the working relationship between the repos is bad, we can do hashing ourselves. I like the util-hashing module for discoverability, people issues aside.

Sam Ritchie
703.662.1337
@sritchie

On Sunday, December 23, 2012 at 1:30 PM, avibryant wrote:

I'll confirm that I'd rather not depend on util, because we've done so well avoiding heavy dependencies so far and I'm loathe to see the first one go in. But that's mostly an aesthetic rather than pragmatic position, so it's loosely held.

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

[johnynek]

#93

util-hashing is published (which will be republished without the fake util-core dependency) which we can start using. I think this is a good idea.

[johnynek]

see #439 #440