#Auto-generated vs ordinary go console application

1 messages · Page 1 of 1 (latest)

acoustic palm
#

Following the docs, it seems that the idiomatic way to write a Go script with Dagger is via dagger init, which generates some code in the internal folder.
But I also saw many examples of people who wrote ordinary go CLI applications, including dagger as a library.
In the latter case, the script contains a main. In the former case, the scripts becomes a collection of functions to be invoked via dagger call.

I am not sure if both ways are valid options, in which case I should prefer one over the other. I could not find info about that.
As a newbie this would help me investing in the right direction.

heady cargo
acoustic palm
#

Thank you. Question: is the generated code not meant to be modified? If so, why isn't it provided in an external, downloadable library?

heady cargo
#

?

acoustic palm
#

Go. Sorry, I forgot to mention.

#

But I am more than open to use a different one. I would use the one that is most likely to be more supported.

#

Or the most popular one. Which one is it, by the way? TS?

heady cargo
#

I'm asking I can explain how code generation works

acoustic palm
#

I'm on C#, F#, Haskell. I tend to prefer statically typed langs.

heady cargo
#

ok, I'll explain Go then

acoustic palm
#

Sure.

#

Thank you for your time and support, already.

heady cargo
#

when you do dagger init --sdk go Dagger generates the following structure:

├── dagger.gen.go
├── dagger.json
├── go.mod
├── go.sum
├── internal
│   ├── dagger
│   │   └── dagger.gen.go
│   ├── querybuilder
│   │   ├── marshal.go
│   │   └── querybuilder.go
│   └── telemetry
│       ├── attrs.go
│       ├── env.go
│       ├── exporters.go
│       ├── init.go
│       ├── live.go
│       ├── logging.go
│       ├── proxy.go
│       ├── span.go
│       └── transform.go
├── LICENSE
└── main.go

Starting from here, the only file you're supposed to modify is main.go and whatevrer other file you decide to create to start growing your pipeline

#

dagger.gen.go and internal do not need to be checked into your VCS (they're in the .gitignore) as Dagger takes care to re-generate those based on your source files each time you call dagger call

#

LMK if that makes sense

acoustic palm
#

I missed the part of excluding internal from git. Makes sense, then.

heady cargo
#

👍

acoustic palm
#

May I ask you a quick one on another topic?

heady cargo
#

sure

acoustic palm
#

I might return a dagger.Container or (error, string), depending if I close with Stdout(ctx) or not

heady cargo
#

dagger call my-func stdout

#

you can also do some other cool stuf like dagger call my-func terminal to jump into a debugging terminal inside that container

acoustic palm
#

That is super cool indeed!

heady cargo
#

or dagger call my-func publish --address ttl.sh/foo to push that container to a registry

#

that's the power a of a strongly typed CI system 💪

acoustic palm
#

What if I have 3 functions, a, b and c, all returning *dagger.Container, and I wish a func z combining the 3.

#

I am not sure how to capture stdout for all of them

#

I noticed that the CLI displays the output, but at the end it cleans all. Maybe I made some mistakes, but I did not find a way to display the output but of the last function.

#

Or, more in general: I did not find a way to have a function returning *dagger.Container and also emitting some debug messages.

#

Shall I just print to stdout

acoustic palm
#

We are hating writing YML files which pretend to be descriptive but are in fact imperative scripts, written in a miserable DSL.

#

We tried Earthly, but Dagger makes so much more sense.

#

So, about the question: imagine we have test, build, package or the like. Each returning *dagger.Container. And all combining the 3.

heady cargo
# acoustic palm What if I have 3 functions, a, b and c, all returning *dagger.Container, and I w...

So Dagger will return to stdout whatever your return from your functions. So you can do something like this:

type TestRet struct {
    One   *dagger.Container
    Two   *dagger.Container
    Three *dagger.Container
}

func (m *Lala) Test() *TestRet {

    return &TestRet{
        One:   dag.Container().From("alpine").WithExec([]string{"echo", "one"}),
        Two:   dag.Container().From("alpine").WithExec([]string{"echo", "two"}),
        Three: dag.Container().From("alpine").WithExec([]string{"echo", "three"}),
    }
}

and then dagger call test one stdout

#

You can still have all the outputs combined in a single string if you want but those might get mixed depending if you're running things in parallel or not

acoustic palm
#

I see. Cool.

#

Thank you. I will keep reading and playing with it. So far, such good vibes.

#

Kudos for creating it.

heady cargo
#

thx for the kind words. We're here to help if you have any questions!

heady cargo
hasty pollen
#

@acoustic palm if you don't mind me asking, how did you find out about Dagger? 🙂

acoustic palm
#

@hasty pollen I actively searched for it. I wanted a build tool which was based on docker or on another technology enabling some reproducibility.

#

I first stumbled upon Earthly, of which I loved some concepts, but which I found kind of limited because of its DSL.

#

Then I found Nix and Dagger.

#

I heard of Nix from many many multiple sources. Dagger was the result of searching solutions for Earthly's limitations.

#

So, I guess I found Dagger from DDG search queries.