#Error initializing Python module - 403 Forbidden on proxy.golang.org

1 messages · Page 1 of 1 (latest)

long forge
#

Hello community! 👋

I'm having an issue when initializing a new Dagger module with the Python SDK.

Command executed:

dagger init --sdk python --name=hello-dagger

Problem encountered:
The process fails during code generation with multiple 403 Forbidden errors when downloading Go dependencies from proxy.golang.org.

Main error excerpts:

go: python-sdk imports
    github.com/distribution/reference@v0.6.0: reading https://proxy.golang.org/github.com/distribution/reference/@v/v0.6.0.zip: 403 Forbidden
    github.com/golang/protobuf@v1.5.4: reading https://proxy.golang.org/github.com/golang/protobuf/@v/v1.5.4.zip: 403 Forbidden

Important context:
I'm running a custom Dagger engine configuration with corporate proxy settings:

docker run --rm -d \
  --name dagger-engine-custom \
  --privileged \
  -v /path/to/cacert.pem:/usr/local/share/ca-certificates/proxy.crt:ro \
  -v /path/to/engine.toml:/etc/dagger/engine.toml \
  -e HTTP_PROXY=http://host.docker.internal:3128 \
  -e HTTPS_PROXY=http://host.docker.internal:3128 \
  -e http_proxy=http://host.docker.internal:3128 \
  -e https_proxy=http://host.docker.internal:3128 \
  -e NO_PROXY="host.docker.internal,*.internal.corp,localhost,127.0.0.1" \
  -e no_proxy="host.docker.internal,*.internal.corp,localhost,127.0.0.1" \
  -e GOPROXY="https://go-proxy.internal.corp" \
  -e GOSUMDB=off \
  -e GOPRIVATE="*.internal.corp" \
  -v /var/lib/dagger \
  registry.dagger.io/engine:v0.18.12

It seems the codegen process might not be respecting the proxy configuration properly.

Questions:

  • Has anyone successfully used Dagger with a corporate proxy setup?
  • Is there additional configuration needed for the Go proxy settings to work during codegen?
  • Any workarounds for this issue?

Thanks in advance for your help! 🙏

long forge
#

Any idea?

regal heron
long forge
# regal heron 👋 checking in a bit 🙏

Thanks for looking into this! 🙏 Much appreciated.

Quick architecture question - when I run dagger init --sdk python, I'm wondering:

  1. Is the code generation happening inside my dagger-engine-custom container (with all the proxy env vars)?
  2. Or does dagger init use a different process/container that might not inherit my proxy configuration?

Trying to understand where exactly the Go module download is happening and why it might not be using my GOPROXY setting. 🤔

regal heron
regal heron
#

the way to test if the proxy works afterwards is execing into the engine container and trying to reach proxy.golang.org

long forge
# regal heron the way to test if the proxy works afterwards is execing into the engine contain...

Thanks for the info! I'm on Mac indeed.

You're right - I can't (and shouldn't) reach proxy.golang.org directly. In our corporate environment, we must use our internal JFrog Artifactory mirror for all Go modules.

I've already set GOPROXY="https://go-proxy.internal.corp" in my custom engine container (pointing to our Artifactory), but it seems the codegen process during dagger init is still trying to reach proxy.golang.org instead of using my GOPROXY setting.

Questions:

  1. Is there a way to force the SDK codegen to respect the GOPROXY environment variable?
  2. Should I also configure something in the engine.toml file for Go proxy settings?
  3. Or is there another place where I need to configure the Go proxy for the init/codegen phase?

The frustrating part is that GOPROXY is set correctly in the engine container, but the error shows it's still trying to use proxy.golang.org 🤔

regal heron
regal heron
# regal heron <@231567611844886528> yes, you need to set `_DAGGER_ENGINE_SYSTEMENV_GOPROXY` i...

this should be added when running the dagger engine. In order to add GOPRIVATE entries to your modules, it's described how it could be achieved here https://docs.dagger.io/api/packages/

Third-Party Packages | Dagger

Dagger Functions are just regular code, written in your usual programming language. One of the key advantages of this approach is that it opens up access to your language's existing ecosystem of packages or modules. You can easily import these packages/modules in your Dagger module via your language's package manager.

long forge
#

@regal heron 🎉 Success! Thank you so much for your help!

The _DAGGER_ENGINE_SYSTEMENV_GOPROXY variable was the key! I can now successfully run dagger init --sdk python.

For anyone facing similar issues with corporate proxies, here's what worked for me on Mac:

docker run --rm -d \
  --name dagger-engine-custom \
  --privileged \
  -v /path/to/cacert.pem:/usr/local/share/ca-certificates/proxy.crt:ro \
  -v /path/to/engine.toml:/etc/dagger/engine.toml \
  -e HTTP_PROXY=http://host.docker.internal:3128 \
  -e HTTPS_PROXY=http://host.docker.internal:3128 \
  -e http_proxy=http://host.docker.internal:3128 \
  -e https_proxy=http://host.docker.internal:3128 \
  -e NO_PROXY="host.docker.internal,*.internal.corp,localhost,127.0.0.1" \
  -e no_proxy="host.docker.internal,*.internal.corp,localhost,127.0.0.1" \
  -e _DAGGER_ENGINE_SYSTEMENV_GOPROXY="https://internal-artifactory.corp/go-proxy/" \
  -v /var/lib/dagger \
  registry.dagger.io/engine:v0.18.12

The crucial part was using _DAGGER_ENGINE_SYSTEMENV_GOPROXY instead of just GOPROXY.

Really appreciate the quick help! 🙏 This community is awesome!

regal heron
long forge