Functions with many flags

[quasi patrol]

The function I'm developing currently has 16 flags (12 of those are optional). In most situations I don't think it'll be an issue but I can see how this may be awkward in some cases. How are folks handling functions with many flags? I'm aware of https://github.com/dagger/dagger/issues/6723 for the future which seems interesting. Most of my flags would be easy to abstract into a config file so I'm considering that, especially since it could have longer term benefits as well. I'd prefer to avoid wrapping dagger in something like Make or Just but I am considering those as well.

[pastel kite]

Im wrapping things in Just and I really like the experience, is there a specific reason why you'd like to avoid this?

I would love to see an experience similar to Just exist within Dagger natively

[quasi patrol]

Mostly because its yet another layer of abstraction. I agree a similar experience within dagger would be ideal.

[pastel kite]

Yeah I also need to remember to install Just everywhere I want to use it, and it leads to the same underlying problem that dagger is trying to solve in not needing to worry about any other local dependencies other than the dagger CLI

Is there an approach from https://github.com/dagger/dagger/issues/6723 that you prefer?

cc @queen peak we were just discussing the same thing this morning 🙂

[quasi patrol]

#2 seems super interesting. Especially if it provided some capability to easily share snippets with my team but also have my own locally, kind of like sharing shell aliases.

I'm also very interested in being able to call dagger functions from an external client as I generally want to reduce the number of tools/clis my users need to install/worry about. Which it would be great if dagger could be the one CLI needed eventually.

[pastel kite]

https://tenor.com/view/to-rule-them-all-lord-gif-12367581

Im sorry I could not resist

I am curous about another thing, is the function you're writing intended to only ever be used via the CLI or do you imagine it being called programatically as well?

[quasi patrol]

This one is mostly intended for CLI consumption as its replacing a number of steps in an existing GHA workflow implementation. If it was more likely to be called programatically I'd make more use of custom types. Though there's probably a couple of situations where I could improve that as is.

[pastel kite]

The main reason I asked is that I have been bitten lately with the fact that "optional" arguments are only optional via the CLI

Im working on an issue for this, I was sad about this for 2-3 params but it feels like it gets even more painful as you go up to 12+

[quasi patrol]

Something else that I could see helping this is to be able to automatically consume some set of environment variables (maybe prefixed with DAGGER_ or a custom prefix). Right now its hard to know "where" my function is executing and if I had some context about the system I could make a few assumptions.

and yeah, it would be very awkward if people were going to call this directly all the time. Thankfully right now its just to match the existing inputs for this github action 😅

[pastel kite]

Yeah agree, that would be awesome. The engine is becoming more aware of things like this but its not exposed to the underlying runtime right now (for example, it can tell if you are in CI or not using some common ENV VAR)

[mystic tapir]

I don't think this is documented but in Go you can overcome this by using anonymous structs.

type Lala struct{}

// Returns a container that echoes whatever string argument is provided
func (m *Lala) Test(ctx context.Context, args struct {
    // +optional
    // +default="hello"
    Foo string
},
) *Container {
    return dag.Container().From("alpine").
        WithExec([]string{"echo", args.Foo})
}

^ this will have the same effect as defining Foo as a stand-alone argument with he benefit that when calling this function from another module, the args struct is optional and any non-defined fields, will use the default value.

[pastel kite]

This is interesting, would this work for other SDKs too? How does it look with code gen?

[undone cargo]

If I may ask, what kinds of flags are we talking about ? Secrets, filenames, settings, other?

[mystic tapir]

yes, this works with other SDK's as well. In this case that Test function is generated as follows:

func (r *Lala) Test(opts ...LalaTestOpts) *Container

as you can see opts is optional.

[halcyon totem]

This is interesting and something I didn't know was possible. This does make calling the same function locally a bit more verbose though. Definitely want to test this.

[quasi patrol]

In my case its mostly various settings like container labels, aws arns, etc.

[undone cargo]

do anonymous structs work in a dagger module? I thought all types had to be named. Maybe Go SDK makes a clever exception for structs in args, and still transforms them into optional args in graphql? In which case the struct name would not matter in this very specific case.

[mystic tapir]

yes, that's the case. AFAIK it was intentionally designed like this for this use-case for Go. cc @opal matrix @valid basin