Re: Are circular dependencies problematic?
On 03/03/2026 13:47, Richard Hansen wrote:
golang.org/x/net and golang.org/x/crypto require each other in their
go.mod files, but I noticed that the golang-golang-x-crypto-dev Debian
package contains a copy of the golang.org/x/net/idna Go package to
break that dependency cycle:
<https://salsa.debian.org/go-team/packages/golang-go.crypto/-/blob/debian/latest/debian/README.source>.
One issue with circular dependencies is when you want to update the
packages to newer version.
Like, you try to bump x/net, but find out it FTFBS because it needs a
more recent x/crypto. So you try to update x/crypto first, but it FTBFS
because it needs a more recent x/net. Now you're stuck, and untangling
this might be tricky and _really_ time-consuming.
I learnt that the hard way with the docker stack years ago. I don't know
if it ever happened in practice with golang.org/x/{net,crypto}.
I'd think a little code vendoring can be better than a circular
dependency. In this particular case, the maintainer of this package
knows best.
Cheers,
Arnaud
Reply to: