If we turn litrpc into a module (which would require turning looprpc etc. into modules as well), we can avoid a bunch of situations with regard to overrides and dependencies. This would make the external (and internal for Loop) development process with Taproot Assets channels significantly smoother and easier. There would be added maintenance work of needing to tag each rpc for any breaking changes.
We would also need to look into proper usage of go.work files and check them in for the rpc stuff. go.work allows the owner of the module to use the local copy without overriding in their go.mod file. However, we need to investigate what happens if you have a go.work file in one repo (let's say lnd) that just points to ./lnrpc for example. Then when you import lnd from a different repo, what version of the lnrpc sub package is then used?
If we wanted to take a look at an example, we do something like this for swapserverrpc.
guggero
commented
1 week ago
If we turn
litrpcinto a module (which would require turninglooprpcetc. into modules as well), we can avoid a bunch of situations with regard to overrides and dependencies. This would make the external (and internal for Loop) development process with Taproot Assets channels significantly smoother and easier. There would be added maintenance work of needing to tag each rpc for any breaking changes.We would also need to look into proper usage of
go.workfiles and check them in for the rpc stuff.go.workallows the owner of the module to use the local copy without overriding in theirgo.modfile. However, we need to investigate what happens if you have ago.workfile in one repo (let's saylnd) that just points to./lnrpcfor example. Then when you importlndfrom a different repo, what version of thelnrpcsub package is then used?If we wanted to take a look at an example, we do something like this for
swapserverrpc.