#How to reference a container?

1 messages · Page 1 of 1 (latest)

hushed shoal
#

When you call a function that returns a container, you get something like this: Container@xxh3:fc442c95cfdd9d34

Is it possible to reuse that container?

Something like: container | from Container@xxh3:fc442c95cfdd9d34 | terminal

I was following the ai agent quickstart and I created a container with the llm-generated curl clone. I wanted to inspect the container and run the app from inside of it, but my original chain of commands did not include | terminal. Is it lost? If not, how can I access that container?

clear mason
# 
ctr=$(container | from alpine)
$ctr | terminal
wheat owl
#

but this only will work in the same dagger shell not across or?

#

the problem I often run into is that the llm produces "uncacheable" layers and I want to have a way to get the resulting container and debug it (often in a new shell environment)

hushed shoal
#

TIL you can create variables in dagger shell.

@clear mason , your example works.

✔ ctr=$(container|from alpine) 0.0s

✔ $ctr 0.0s
Container@xxh3:0991463b40bf15ca

it seems strange that you can capture the return value into a variable and reference it later, but you cannot reference the container directly within the same session.

in the AI agent example, the user is spending $ on tokens, and if they don't capture the container in a variable, or do |terminal, then there is no way to access it?

@wheat owl -- im getting an "unbound variable" if i try to reference it in another dagger session. it doesn't persist, as far as i can tell.

empty goblet
# wheat owl the problem I often run into is that the llm produces "uncacheable" layers and I...

👋 ~~there's currently a way to achieve this but it requires a custom function module. i.e if you have a function like this (can be in any SDK): ~~

type Debugger struct{}

// Returns a container that echoes whatever string argument is provided
func (m *Debugger) Debug(id string) *dagger.Container {
    return dag.LoadContainerFromID(dagger.ContainerID(id))
}

edit: you can achieve the same thing as above with .core | load-container-from-id $id

you can then get the ID of the container you want to debug with something like: llm | with-env $(env --privileged --writable) | with-prompt "create an alpine contaner and save it to the pepe variable" | env | output pepe | as-container | sync.

The sync call with give you a container ID that you can then pass to the debug function with dagger call $id terminal. That will give you a debug terminal of that container.

It used to be that you could call loadContainerFromID from the shell but it doesn't seem to be the case anymore. ccing @sweet crane for visibility

sweet crane
#

probably .core | load-container-from-id

empty goblet
sweet crane
#

context for why you can't copy-pasye: the short ID shown by the shell is just a human-friendly digest. the real ID is much larger, showing it every time would drown the terminal

but in reality we could keep a lookup table...

stuck lion
# wheat owl the problem I often run into is that the llm produces "uncacheable" layers and I...

what sorts of "uncacheable" layers?

Is the idea that an LLM loop does work with Dagger functions as tools, but you can't always just play that back or get the state reached up to a point?

Or are you describing the point where you can ask for the same llm | with-env| with-prompt | foo | bar | baz and will get it back from cache and then a point where it gets recalculated (new session).

I've wanted to be able to capture everything in the DAG including commands run in a terminal. It feels like we could run terminal commands through a shim to capture thoses as a sort of WithExec() like a ShellExec() or something.

small gale
empty goblet
#

shall we add .core to the .help output? I can send a PR really quick for that

small gale
#

It’s intentionally hidden, by request. I’m not opposed to unhiding though, and it was before a bunch of commands being added for llm.