#Hey folks I have a question regarding

1 messages · Page 1 of 1 (latest)

velvet terrace
junior bridge
velvet terrace
#

local ones:

  "dependencies": [
    {
      "name": "github",
      "source": "modules/github"
    },
    {
      "name": "workspace",
      "source": "modules/workspace"
    }
  ],
  "clients": [
    {
      "generator": "go",
      "directory": "./internal/dagger"
    }
  ]
junior bridge
#

Okay and when you are building your binary, does it has access to the dagger.json?

velvet terrace
#

nope does it need it? 😄

#

I thought this is going to get embeddet into it as the modules are all in go as well 😄

junior bridge
#

Hmm

velvet terrace
#

so if I scp the built binary I need to copy the local modules + the dagger.json as well?

junior bridge
#

Yeah you'll need them

#

Otherwise the modules are not loaded in the engine on invokation, we do not automatically bundle the local modules

#

The best would be to make these modules public, so you don't have to do this

velvet terrace
#

Good to know and easy to workaround for now 🙂 Would be great though if this could be bundled in the future with the main binary as well

junior bridge
#

If you depends on remote module, they are automatically loaded on invocation because they can be accessible from everywhere

junior bridge
#

We also assumed that published binaries would depends on remote modules, if you treat your dagger modules as dependencies, you usually use published libraries, it's not often that you vendored some deps ^^

velvet terrace
#

makes sense I'm more expolring the possiblities yet with dagger to see how far we can get 😉 so not thought about publishing more how can I run it now on a vm

#

In regards to:

The generated code inside the dagger/dag/dag.gen.go seems to have some issues with the generated client for my Workspace module

Is there a way to fix the dag.gen.go? as this fails sadly my go tests when running with go test ./...

junior bridge
#

I see, so yeah I would recommand to either run it with go run or publish your packages

#

You can also fix it manually

#

Basically you need to do that:

// In dag/dag.gen.go

    dagClient "dagger.io/dagger"
    dagger <link to your module dagger dir>
)

var client *dagger.Client
var clientMu sync.Mutex

func initClient() *dagger.Client {
    clientMu.Lock()
    defer clientMu.Unlock()

    if client == nil {
        opts := []dagClient.ClientOpt{
            dagClient.WithLogOutput(os.Stdout),
        }

        ctx := context.Background()

        var err error
        client, err = dagger.Connect(ctx, opts...)
        if err != nil {
            panic(err)
        }
    }
    return client
}
#

And

#

In your dagger.gen.go (jump to Connect to be at the right place)

// Client is the Dagger Engine Client
type Client struct {
    dag *dagger.Client

    query  *querybuilder.Selection
    client graphql.Client
}

func Connect(ctx context.Context, opts ...dagger.ClientOpt) (*Client, error) {
    dag, err := dagger.Connect(ctx, opts...)
    if err != nil {
        return nil, err
    }

    c := &Client{
        query:  dag.QueryBuilder(),
        client: dag.GraphQLClient(),
        dag:    dag,
    }

    if err := serveModuleDependencies(ctx, c); err != nil {
        return nil, err
    }

    return c, nil
}

func (c *Client) Close() error {
    return c.dag.Close()
}
#

Not that if you regenerate your client (with dagger develop), the changes will not be saved so you'll need to do them again sadly

velvet terrace
#

Back to the dagger.json file that needs to be copied as well along the binary. Is there a way to tell teh dagger.Connect where the location is or must it always be aside of the binary?

junior bridge
#

It needs to be aside of the binary

#

If you put your bin in a docker image, you can simply copy the dagger.json and the modules source codes in your image, it should work

#

Note that you need to respect the paths defined in your dagger.json

velvet terrace
#

sure makes sense! awesome thanks so much for your help!

junior bridge
#

No problem! Let me know if you need anything else 😄

velvet terrace
#

Of course one more question came up in my mind 😂

Can you explain when I need the dag.gen.go vs the dagger.gen.go? I'm currently always importing from the dagger.gen.go via "internal/dagger".
In which cases to import from where and wha'ts the purpose of the dag?

junior bridge
# velvet terrace Of course one more question came up in my mind 😂 Can you explain when I need ...

That's a good question! For client generation, we generate 2 packages:

dagger/ (by default)
  dagger.gen.go
  dag/
    dag.gen.go

So the dag package is for the global client, with it you can directly call the Dagger API without explicitely connect to the engine. It's a convenient way if you don't want to manage the connection by yourself.

The dagger package is the complete binding to your engine API and let you use the Connect function to explicitly create a client.

func main() {
  ctx := context.Background()
  c, err := dagger.Connect(ctx)
  if err != nil { ... }

  c.Container().From(.....
}

// OR

func main() {
  // No explicit connection, it's managed inside the global client package.
  dag.Container().From(....
}
junior bridge