We’ve just prepared our first prerelease of JupyterHub-traefik-proxy 1.0, which updates support to traefik v2.
Check out the changes, especially if you use an external traefik proxy, which means you need to update traefik and your traefik config files. Give it a try and let us know how it goes.
Thanks to everyone who contributed!
That makes sense! I’ve never packaged a go package for conda-forge, but I can look into it.
As helpfully noted on the above link to staged-recipes: traefik is currently blocked by one of several PRs to get go 1.19, several of which appear… close?
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: