After that, the recipe itself usually isn’t that big a deal: there’s a handy tool for grabbing all the vendored licenses which takes much of the historical manual pain away.
There are some good examples out there… i usually point people at e.g. minikube. Really just depends on how fancy their build is, and how many c/c++ dependencies are used.
The real win is when go/rust upstreams provide a “fat” source distribution, with all of the packages already resolved, but this is not particularly common. But then I’ve also seen go packages that only build inside a specific docker container. Ick.
I’ve packaged a few go packages for conda-forge. The main complication is that go has built-in support for cross-complication, which means some projects include cross-compiled targets by default in their makefile/build scripts. If the build script itself is written in go, or the project uses other go tools that are compiled on the fly, this fails with conda-forge cross-complication because it builds those tools for the cross-compiled target… then attempts to run it in the host environment which fails. The solution is to disable the conda-forge cross-compilation env vars and leave it to the original projects build scripts.
At first glance traefik doesn’t look like it does anything funny: