Use patched go-ethereum from fork instead of patching it on-the-fly

[adambabik]

Instead of patching code after running dep ensure, use a patched fork.

The problem I encountered is that it's impossible to use status-go as a package due to patches on its dependency, mainly github.com/ethereum/go-ethereum. Even if dep is able to resolve dependencies, compiling will fail due to code differences between github.com/ethereum/go-ethereum and patched version that status-go uses.

A proposed solution is to use change source of github.com/ethereum/go-ethereum in Gopkg.toml to our fork:

[[constraint]]
  name = "github.com/ethereum/go-ethereum"
  version = "=v1.8.14"
  source = "github.com/status-im/go-ethereum"

After this operation, I am able to create a new project with the following Gopkg.toml:

[[constraint]]
  name = "github.com/ethereum/go-ethereum"
  version = "=v1.8.14"
  source = "github.com/status-im/go-ethereum"

[[constraint]]
  name = "github.com/status-im/status-go"
  version = "=v0.14.1"

# I skipped some additional issues with go-ethereum like pruning non-go packages.

Todo

• remove vendor-check and update-geth,
• change patch and patch-revert so they work on our go-ethereum fork,
• update readme in _assets/patches/geth.

[divan]

I'm generally now more in favour of this approach because it will help in switching to Go modules, but I don't really get the moment of:

is that it's impossible to use status-go as a package due to patches on its dependency

Why it's not impossible? We're not patching on-the-fly, only when bumping up go-ethereum version, right? Or am I missing something?

[adambabik]

@divan because if you use github.com/status-im/status-go as a dependency, it implicitly requires github.com/ethereum/go-ethereum as well, however, it's not taken from github.com/status-im/status-go's vendor directory which is the only place where it's patched. Instead, it gets it from github.com/ethereum/go-ethereum so you end up with non-patched code.

[mandrigin]

Make sure that the research team is aware of this changes so they don’t break the fork repo.

[dshulyak]

@adambabik if fork is patched instead of vendored copy, what is the reason to keep patches in status-go?

[adambabik]

@dshulyak it's actually hard to figure out a good place for the patches in our fork. We can have a special branch in our fork where patches could live. Now, if a new version appears, we would checkout them from that branch and apply on the new version branch. It seems like the same effort.

But primarily, I wanted to do as few changes as possible. When using a fork, we can can also think about getting rid of the patches completely. We could have patched/1.8 long-running branch with our changes and merge new versions on top of it like this git merge upstream/v1.8.15.