In order to remove go-ethereum (replaced with plugeth) as a dependency and the workarounds needed to make this work with Go's plugin architecture (see #2 (comment); worked around by forking plugeth to move its main to separate module, plus CGO linking patches) we will have to completely refactor the go-ethereum types to use corresponding types from plugeth-utils.
We need to evaluate the impact this will have on other tooling that depends on the statediffing code.
Many tests use Geth's helpers for chain generation and manipulation, so those will need to be cloned, along with other utilities. If feasible, it may be worth moving such tests to a separate module which can make use of both this code and parts of Geth.
In order to remove `go-ethereum` (replaced with `plugeth`) as a dependency and the workarounds needed to make this work with Go's plugin architecture (see https://git.vdb.to/cerc-io/plugeth-statediff/pulls/2#user-content-plugeth-fork; worked around by forking plugeth to move its `main` to separate module, plus CGO linking patches) we will have to completely refactor the `go-ethereum` types to use corresponding types from `plugeth-utils`.
* We need to evaluate the impact this will have on other tooling that depends on the statediffing code.
* Many tests use Geth's helpers for chain generation and manipulation, so those will need to be cloned, along with other utilities. If feasible, it may be worth moving such tests to a separate module which can make use of both this code and parts of Geth.
roysc
self-assigned this 2023-09-14 13:11:56 +00:00
Yes: since Plugeth plugins are intended to be built without any Go-level dependencies on go-ethereum/plugeth, and all interfacing with Geth types going through plugeth-utils. This prevents the need to 1. exactly match dependency versions, and 2. for the workaround described in the original Plugeth PR:
Due to a limitation with Go plugins, building a distributable plugin doesn't work if the main module is a dependency of the plugin, so I forked plugeth and added a nested proxy module (wrapmain) which just imports and runs the plugeth cmd package.
But it means extensive refactoring as described above. When we are able/want to switch to stock plugeth, we will need to do this (or upstream the workarounds, but I doubt they want to support this case).
Yes: since Plugeth plugins are intended to be built without any Go-level dependencies on `go-ethereum`/`plugeth`, and all interfacing with Geth types going through `plugeth-utils`. This prevents the need to 1. exactly match dependency versions, and 2. for the workaround [described in the original Plugeth PR](https://git.vdb.to/cerc-io/plugeth-statediff/pulls/2#user-content-plugeth-fork):
> Due to a [limitation with Go plugins](https://github.com/golang/go/issues/31354), building a distributable plugin doesn't work if the main module is a dependency of the plugin, so I [forked plugeth](https://git.vdb.to/cerc-io/plugeth/src/branch/statediff-wip) and added a nested proxy module (`wrapmain`) which just imports and runs the plugeth `cmd` package.
But it means extensive refactoring as described above. When we are able/want to switch to stock plugeth, we will need to do this (or upstream the workarounds, but I doubt they want to support this case).
roysc
changed title from Remove dependence on Geth to Fully replace `go-ethereum` imports with `plugeth-utils`2023-10-31 04:34:02 +00:00
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
In order to remove
go-ethereum(replaced withplugeth) as a dependency and the workarounds needed to make this work with Go's plugin architecture (see #2 (comment); worked around by forking plugeth to move itsmainto separate module, plus CGO linking patches) we will have to completely refactor thego-ethereumtypes to use corresponding types fromplugeth-utils.We need to evaluate the impact this will have on other tooling that depends on the statediffing code.
Many tests use Geth's helpers for chain generation and manipulation, so those will need to be cloned, along with other utilities. If feasible, it may be worth moving such tests to a separate module which can make use of both this code and parts of Geth.
Is this still a thing?
Yes: since Plugeth plugins are intended to be built without any Go-level dependencies on
go-ethereum/plugeth, and all interfacing with Geth types going throughplugeth-utils. This prevents the need to 1. exactly match dependency versions, and 2. for the workaround described in the original Plugeth PR:But it means extensive refactoring as described above. When we are able/want to switch to stock plugeth, we will need to do this (or upstream the workarounds, but I doubt they want to support this case).
Remove dependence on Gethto Fully replace `go-ethereum` imports with `plugeth-utils`