daggernauts

[sharp zealot]

yeah that's the remaining puzzle... We're dealing with this for @warped canyon 's playwright module too. Every playwright configuration needs a single service to target... So how do you select that service in a way that is both 1) configurable by the end user, 2) programmable by higher-level modules

Clearly, the first step is: a global module setting (user-friendly name for "module constructor argument") of type Container

So let me do that next 🙂

[thorn moat]

uh oh - do we need a dependency injection framework

like...dagger? (https://dagger.dev/)

[sharp zealot]

Mmm I don't think so it will just be a regular argument

[thorn moat]

yeah but the dependency injection framework is what magically fills in that argument with its all-knowing knowledge

since nothing in the user's code actually calls that function, there's no opportunity for them to actually pass an argument (afaik?)

(i've never actually used a DI framework and historically thought they were dumb vs. just passing arguments, to be clear, just exploring the thought since it seems to match the use case)

[sharp zealot]

users see it as a setting

dagger settings go base-image docker.io/my/image

which will add one line to .dagger/config.toml

[thorn moat]

definitely makes sense for simple values

[sharp zealot]

You're worried about the "config becomes pseudo-code" risk?

[thorn moat]

not acutely, just still have the open question about how to map it to a function that e.g. builds an image using apko with all my favorite dependencies installed

wonder if interfaces could help at all, too

[sharp zealot]

Right. We're betting on artifacts / collections for that. Since it gives us a coordinate system for uniquely selecting any artifact (and any individual "verb" on that artifact). And an API for making that selection in the workspace.

The idea is to also define a selector syntax for expressing such selector in a string. Then incorporate that in the address API, so users can specify those selectors.

Now to find the thread for that...

(searching for threads)

Unrelated @thorn moat : is dang sensitive to loading order of files?

[warped canyon]

did you see this too @thorn moat ? #maintainers message

[sharp zealot]

LLM is convinced that it is, and prefixing my files with 00-, 01- etc

[thorn moat]

it shouldn't be - it loads all files in a directory and works out the inter-dependencies, but there may be bugs, it's pretty complicated to implement

[thorn moat]

that definitely seems cool but i fear there'd still be cases where it's not enough. i've flirted with similar ideas, e.g. Doug had something like Bash(args []string, packages []string) at one point to run a command with packages magically installed

[warped canyon]

the proposal I had for playwright Service deps is here https://github.com/dagger/dagger/pull/13016

[sharp zealot]

Found it! https://discord.com/channels/707636530424053791/1492056612506959964

[sharp zealot]

Somehow missed this... I guess a follow-up to our discussion in https://discord.com/channels/707636530424053791/1492056612506959964

[warped canyon]

yes exactly. I opened it as a proposal and started a discussion thread in discord but no bites yet 😉

[sharp zealot]

Fun fact: if you forward your ssh agent into an ephemeral container, you get your local ssh credentials for free 🙂

Example

Make sure you have ssh identities added... ssh-add ...

dagger core container \
 from --address=alpine \
 with-exec --cmd=apk,add,openssh \
 with-unix-socket --path=$SSH_AUTH_SOCK --source=$SSH_AUTH_SOCK \
 with-env-variable --name=SSH_AUTH_SOCK --value=$SSH_AUTH_SOCK \
 terminal

Now I just need to figure out how to get apk to work on the engine playground...

[sharp zealot]

Another cool discovery: a @generate function is a great way to drop skills in a repo 🙂

[sharp zealot]

FYI we've agreed yesterday that the workspace branch will soon be tagged with 1.0.0-beta1 and we will start beta-testing for 1.0 even before we merge it

Then after merging, we will continue 1.0 beta testing as needed off of main

[sharp zealot]

This one's interesting @thorn moat :

• PR to add support for custom base image in dagger/go (as requested)
• base and version are mutually exclusive - we can only guarantee version on the default base image
• to enforce mutually exclusive arguments, we must switch to explicit constructor
• the resulting diff is large, because all public fields must now be part of this custom constructor

This might be fine actually. It just caught my eye, though I'd pass it on

https://github.com/dagger/go/pull/11

[thorn moat]

huh yeah, bit of a bumpy transition once you get used to having all the fields automatically being arguments (assuming you want to keep all of them)

there's a tension here - an alternative could be not adding all those args and using withFoo pattern instead, but maybe there's a reason to avoid that, like constructor args being more natural to expose through config - is that at play?

[sharp zealot]

Oh yeah, that ship has sailed for user-facing modules... dagger settings is built on the assumption that a module's constructor arguments are part of the UI

(strictly for user-facing configuration)

that's what all those arguments are for in my case

[dense canyon]

@restive shore around? By any chance do you have an opinion about this? https://github.com/dagger/dagger/issues/13174

looking for a Java experienced human to challenge LLMs on this one

[restive shore]

let me check

[dense canyon]

thx. We think it makes sense but just want to double check 🙏 cc @muted plank

[restive shore]

I think it makes sense. I haven't used that myself but I don't see how that could break things either.

Good to try it out though

[dense canyon]

yeah same. If it doesn't raise any suspicions then we agree it seems ok to merge

[restive shore]

I don't see a PR tied to that issue

[muted plank]

Yeah we'll open it

[restive shore]

I have an unrelated question. Is dagger ready for checked in generated code? I remember there was a PR around having a flag that prevents code gen at runtime. Is that already released? Even without codegen prevention, is it workable to have the code gen committed to repo and then doing linting (golangci-lint) without re-generating code?

[dense canyon]

yep, we have checked-in the code ourselves in the dagger/dagger repo and haven't found any issues so far. cc @sharp zealot

[restive shore]

I should use dagger develop right? Or dagger generate?

[warped canyon]

develop for the moment, generate soon 🙂 we also have some upcoming improvements so that if you have committed the generated files, they won't be regenerated at runtime (unless you want them to be)

[restive shore]

Right, the "regenerate at runtime" was what I was referring to earlier. I guess that's coming up 🙂 Does dagger run golangci-lint directly on the checked in code? Or via dagger?

[warped canyon]

via dagger, however now we can use a generic module that isn't dagger-aware, meaning it doesn't have to create the generated files before linting

[restive shore]

Can you point me to that code please?

[warped canyon]

yup here's the module we're using in ci today: https://github.com/dagger/dagger/blob/main/toolchains/go/main.go

soon (maybe now, not confident on the current state) you'll be able to use github.com/dagger/go instead of modules inside dagger/dagger for faster checkouts. We have a handful of official modules we've been building for this purpose each in their own repos

[restive shore]

I've been keeping an eye on that. We have our own modules, so, I haven't really put any thought into how that would translate.

[warped canyon]

My hope is that with 1.0 you'll be able to remove most of the code in your own modules to use the generic ones and only worry about maintaining the stuff that is really specialized for your projects. I think a lot of people will just be able to use our modules, but probably not you guys 😛