Some packages and files, especially in accounts/... are not appropriately placed. We should move them to better places in order to make them more visible and better fitting. The changes could either be done seperately or all in once to create only a single breaking change for users.
In the following description, I'll use / to indicate the top level directory and * to indicate all files within a directory.
I think this change is pretty straight forward, the abi package is not really related to accounts and thus should not be buried in it. Moving this package would be a major change and impact all users of go-ethereum that use the abi. Additionally I would like to move the topics (+tests) to the abi package. As already pointed out in ethereum/go-ethereum#20275, moving the topics to the abi package could help us create more unified encoding and decoding tests. Moving topics would not be a breaking change for most users. So I would move:
- /accounts/abi/bind/topics.go to /accounts/abi/topics.go
- /accounts/abi/* to /abi/*
I think creating a new folder (backend or client) for all packages that implement the /backends/backend.go interfaces (currently only ethclient and simulatedbackend) might make sense to bundle them together.
- /accounts/abi/bind/backends/* to /accounts/abi/bind/backends/simulated
- /accounts/abi/bind/backend.go to /backends/backend.go
- /accounts/abi/bind/backends/ to /backends/*
- /ethclient/* to /backends/ethclient/*
Resulting in the following structure
- backends
- backend.go
- simulated
- simulated.go
- ethclient
- ethclient.go
There are a lot of problems associated with moves of this size. All projects that currently depend on /accounts/abi /accounts/abi/bind /accounts/abi/backend and /ethclient would need to update their code to reflect the changes. Additionally all dependencies within go-ethereum would have to be updated (fortunately not that many).
For
vendor
mode project, it's ok for moving. While forgo mod
mode project, unless they upgrade thego-ethereum
dependency explicitly, it still won't affect the usage of the old library. But yes if they upgrade it, then they need to change the import path of dependency.