Confused with module attributes

[modern vapor]

Hey all, I am currently developing a dagger module to be exposed through mcp, but right now I am confused with the way dagger (or maybe my python knowledge), that somehow updating attributes doesn't work

@object_type
class Agent:

    start: Annotated[dagger.Directory, DefaultPath(".")]
    ctr: Annotated[dagger.Container, Doc("Spacelift container for managing Terraform operations")] = field(default=(dag.container()
                                                                                                                          .from_("alpine")))

    @function
    async def init(self, token : Annotated[dagger.Secret, Doc("Token")]) -> Self:
      self.ctr = self.ctr.with_secret_variable("SECRET_TOKEN", token).with_directory("/work", self.start).with_workdir("/work")
        return self

    @function
    async def check(self) -> str:
      return await (self.ctr.with_exec(["env"]).stdout())

when I call init, then check, the output doesnt contains SECRET_TOKEN. It seems like the self.ctr assignment doesnt work. Did I misunderstand the behavior here? I saw this pattern multiple times especially when create a workspace module to be used in LLM.

But when I chain the command like init env://SECRET_TOKEN | check it works as expected. Did I misunderstand the way it works ?

[quasi seal]

when I call init, then check

Can you clarify how you do this exactly?

[visual kindle]

I call init, then check,

if you're doing:

dagger call init 
dagger call check

then check ctr will not have the secret since init is never called in the first place within the same dagger session.

If you want self.ctr to always have the secret, you can use constructors (https://docs.dagger.io/api/constructor/) so self.ctr is always initialized with the secret in the class consturctor

that way you don't necessarily have to call init every time

[quasi seal]

Yeah that init looks like it could be a constructor

But also, if you call init and check separately like @visual kindle described, you are calling both functions from the same starting point. If you want to combine the effects of both functions in the same object, you need to chain the function calls

The 2 separate sessions are a separate problem I think @visual kindle. Even if they did this:

dagger -c 'init; check'

The problem would remain

[visual kindle]

yes correct. Same principle applies as if you were using any other repl.

i.e

new Agent().Init()
new Agent().Check()

^ the above won't have the secret since init is never called in the check method

what you want to do is

a = new Agent().Init()
a.Check()

which is the equivalent in dagger:

dagger -c 'a=$(. | init); a | check`
or simply: 
dagger -c 'init | check`

[bitter stump]

I tried using interactive terminal. Calling init, then check. I believe I need to learn more about that dagger session.

Initially I thought when running dagger interactive, it will be the same session, thus calling init, then check without pipe resulting the desired output

Why I ended up with this question is because I saw this line https://github.com/kpenfound/dag/blob/7713920d272b2f990fa50eee5a2da53829168db6/workspace/src/workspace/main.py#L89 works on llm.

[quasi seal]

@bitter stump ignore the part about sessions, it doesn't matter.

What's important is that Dagger objects, are immutable and content-addressed. When you call a function that returns a new object, you need to do something with that returned object - either feed it into another function call, or save it to a variable - otherwise it is lost.

[quasi seal]

in this line, the function is modifying a temporary private copy of its object. Note that immediately after, it returns that modified copy to the caller. If it didn't, the modified copy would be lost.

Think of each Dagger function as a machine on a factory line: it receives inputs from the conveyor belt; performs an action; then sends outputs down the conveyor belt.

[bitter stump]

That’s analogy of conveyor belt clear up a bit, but I still a little bit confused.

On init function from example, it does returns self. Does this means it returns the modified copy?

[quasi seal]

yes