#Toolchains v2 🧵

1 messages · Page 1 of 1 (latest)

frigid oxide
#

Scary name 😛 Just splitting up threads.

#

This one is for the nitty-gritty of the breaking change to toolchain API, for explicit env

#

@river anchor I'm going to try a POC

#

@river anchor just to confirm the current currentEnv() behavior... When called from a regular function, it sets the workspace to the current module's context dir... so that is a snapshot of the context with only the include filters needed for loading the module, right? The rest of the context will be missing. Correct?

#

Or, is it a full upload of the full context directory with zero filter?

#

Just understanding my starting point

river anchor
#

yeah, it's pretty broken tbh, it started as a best approximation of what it should mean, and was never load-bearing

frigid oxide
#

OK just testing my understanding 🙂

river anchor
#

(so it's just the module source, not the rest of the context dir)

frigid oxide
#

So, first order of business is attaching some rudimentary dynamic filtering to Env, so that I can actually use it as a defaultPath replacement

river anchor
#

agreed

frigid oxide
#

OK then 🙂

#

Also: that means creating a new intermediary type between Env and the final Directory to be Produced

#

Basically a type to represent a live filesystem, backed by session att

#

Filesystem?

#

And while we're at it, we could design a first-class concept of workdir/navigation within that, so you can chdir perhaps

river anchor
#

or you could do Env.directory(path) like Host does, if you want to shortcut all that (unsure if that's a desireable scope creep or a speed bump)

frigid oxide
#

So then that's 2 types:

  • Filesystem (the whole thing)
  • FilesystemSession? for the navigation with mutable workdir
#

Or maybe I just add an optional workdir (path) argument to every Filesystem function, and that's enough nah doesn't make sense

#

Also need to resolve the eternal dichotomy between "host filesystem" and "workspace"

#

Mmm let me first investigate the current reality of our session attachables. I don't actually know how that handles the concept of workdir, relative paths etc

#

It's going to get interesting when we get to the "execute command on the host" session attachable 😛

frigid oxide
#

@river anchor another random design question sorry.

In this brave new world, does dagger -m become too ambiguous? It could mean either "load the functions implemented by this module so I can call them" or "enter this project so I can use it as context to call functions implemented by its toolchains"

river anchor
#

i suppose it wouldn't need to be ambiguous since the module denoted by the path would always be either one or the other (based on whether the constructor takes an Env), but if it helps DX we could add a -e/--env flag or something

frigid oxide
#

I wonder if I should start with a placeholder type distinct from Env... then merge it back in once it works. Otherwise the initial complexity might be a little much.. For example there are parts of contextual arg loading, that check if there is an env attach to context... I guess to handle the case where the function is called by llm in the context of a sandboxed env with workspace. If I wrap all this in another Env, it might get hairy

river anchor
#

(Can theoretically be deleted because that's to support currentEnv and defaultPath for LLM-attached modules, which will both be replaced by Env in constructor anyway)

frigid oxide