Seems like the big obstacle is that go-ethereum doesn't love being vendored b/c the dang crypto...secp256k1 C files aren't included with dependency managers like govendor or dep. Does that seem right to you?
I can't really think of an elegant way to get those included programmatically... the base Dockerfile wants to be slim and not go messing around with git cloneing, curling, or otherwise grabbing the C files it needs, and it doesn't seem like adding an extra env.sh or setup.sh step (or whatever) is the best solve either.
These inelegant solutions lead me to consider the position of chaintools and how it relates to Hive. On one hand it seems like functionality that's nice to have close because it relates directly to generating crucial test and reference data, on the other it's starting to smell like chaintools might want to become it's own thing; maybe generating that kind of data is something that more than just Hive would want to do, but seems like it'd be a bummer to remove from Hive entirely.
I'm working on a development "fork" of chaintools that would let us possibly use a go plugin shared object chaintools.so that could be static and versioned in the Hive repo. This'd let us remove the messy go-ethereum dependency and keep the chaintools tooling available and reproduceable. Then it's just up to the devs to pick/bump the chaintools.so artifact version composition when relevant.
One major downside to this is that go plugins aren't Windows friendly. That could be solved only-kind-of-hackily by just using the chaintools lib as a dep, and then deal with the current go-ethereum dependency stray C files issue also only-kind-of-hackily.
After all this, I'm wondering if for the time being (especially considering Windows extra complexity) that maybe the thing to do is just slap the go-ethereum package in Hive, manually put the crypto C files in there, and call it a day.
meowsbits
commented
5 years ago
Seems like the big obstacle is that
go-ethereumdoesn't love being vendored b/c the dangcrypto...secp256k1C files aren't included with dependency managers like govendor or dep. Does that seem right to you?I can't really think of an elegant way to get those included programmatically... the base Dockerfile wants to be slim and not go messing around with
git cloneing,curling, or otherwise grabbing the C files it needs, and it doesn't seem like adding an extraenv.shorsetup.shstep (or whatever) is the best solve either.These inelegant solutions lead me to consider the position of
chaintoolsand how it relates to Hive. On one hand it seems like functionality that's nice to have close because it relates directly to generating crucial test and reference data, on the other it's starting to smell likechaintoolsmight want to become it's own thing; maybe generating that kind of data is something that more than just Hive would want to do, but seems like it'd be a bummer to remove from Hive entirely.I'm working on a development "fork" of chaintools that would let us possibly use a go plugin shared object
chaintools.sothat could be static and versioned in the Hive repo. This'd let us remove the messygo-ethereumdependency and keep thechaintoolstooling available and reproduceable. Then it's just up to the devs to pick/bump thechaintools.soartifact version composition when relevant.One major downside to this is that go plugins aren't Windows friendly. That could be solved only-kind-of-hackily by just using the
chaintoolslib as a dep, and then deal with the currentgo-ethereumdependency stray C files issue also only-kind-of-hackily.After all this, I'm wondering if for the time being (especially considering Windows extra complexity) that maybe the thing to do is just slap the go-ethereum package in Hive, manually put the crypto C files in there, and call it a day.