-
Notifications
You must be signed in to change notification settings - Fork 4
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Proposal: Remove dependency on NebulousLabs/Sia #13
Comments
Follow up: I wasn't 100% sure that NebulousLabs/Sia was responsible for the large binaries, so I fact-checked myself using the goweight tool. This tool indicates that indeed, a sizeable percentage of a binary like However, when I tried another tool, it indicated that NebulousLabs packages are only responsible for about 1.6% of the compiled binary. The only way to truly be sure is to strip out the dependency, recompile, and see how much smaller the binary is. Unfortunately, that requires a fair amount of work. Still, even if binaries don't shrink as much as I'd hoped, there are other reasons why removing the dependency is desirable. In particular, it drags a ton of packages into our go.sum, which makes a proper audit far more difficult. See the attached graph; if not for Of those, |
This is a significant issue for us, too. The problem is NebulousLabs/Sia tends to print a stack trace instead of panicking when some critical errors occur. For example, we got this:
This behaviour doesn't work for us because of these reasons:
Although we can customize this |
In fairness, anything that triggers a build.Critical is a developer error that I should fix immediately. But yeah, I would use a normal panic for that. |
us
does not strongly depend on the NebulousLabs/Sia packages; most of the references are to small types likemodules.NetAddress
,types.BlockHeight
, etc. However, even a single reference is sufficient to drag in the entire repo as a dependency, which significantly bloats the size of binaries that importus
packages. This also impacts the us bindings: the resulting ObjC framework, for example, is 53 MB, which is just crazy.Unfortunately, there are a few places where the dependency is hard to remove. In particular,
wallet.ChainScanner
needs to implementmodules.ConsensusSetSubscriber
, which means it must depend on themodules.ConsensusChange
type. Additionally, if we substitute our own types for NebulousLabs/Sia types, it becomes harder to write code that interoperates with bothus
and NebulousLabs/Sia.I propose that we make two changes:
interop
package to us-bindings that converts betweenus
types and NebulousLabs/Sia types.To solve the
wallet.ChainScanner
problem, we would redefine the method to depend on a locally-defined copy ofmodules.ConsensusChange
, and then callinterop.ToConsensusSetSubscriber
on it to make it satisfymodules.ConsensusSetSubscriber
. This is viable because we only need to actually subscribe to the consensus set in binaries likewalrus
and during certain tests, so you only "pay for" the NebulousLabs/Sia dependency when you actually need it. Accordingly, the bindings should shrink enormously.The text was updated successfully, but these errors were encountered: