Typescript SDK: How to mount / copy a local dir?

[heady tiger]

With the attached screenshot as reference, I can't figure out how to mount ( copy? ) a local directory on my machine to into the Dagger engine so it can operate on it?

I've tried to do something along the lines of...

const srcDir = new Directory();
srcDir.withDirectory(...)

along with a few other things and don't quite see how to do this properly?

[wide cradle]

I was going through the docs yesterday and this worked for me

  @func()
  async tree(dir: Directory, depth: string): Promise<string> {
    return await dag 
      .container()
      .from("alpine:latest")
      .withMountedDirectory("/mnt", dir)
      .withWorkdir("/mnt")
      .withExec(["apk", "add", "tree"])
      .withExec(["tree", "-L", depth])
      .stdout()
  }

https://docs.dagger.io/developer-guide/typescript/292372/functions#arguments

[heady tiger]

That makes a bit of sense. I guess the confusin part here is how do I contruct the Directory type properly with a path a excludes?

[wide cradle]

I see what you mean, In the example I shared you pass it as an argument like this:

dagger call tree --dir=. --depth=1

I think this is the preferred way of doing things now rather than trying to read the directory from inside the container. If you want to exclude paths, that is a good question, there was an older way[1] to do this but I am not sure how it works now. @dawn pendant or @royal oasis do you happen to know off hand?

Old way: https://archive.docs.dagger.io/0.9/cookbook/#get-host-directory-with-filters

I do see this now: https://docs.dagger.io/reference/typescript/classes/api_client_gen.Directory#withoutdirectory

[royal oasis]

Great question 😄 If there's something specific your function always wants to drop, like node_modules, using withoutDirectory might help. The proper way to do this from the CLI is still being sorted out
https://github.com/dagger/dagger/pull/6701
https://github.com/dagger/dagger/issues/6155

[heady tiger]

Gotcha. For something running from a proper CI runner, excluding stuff is less important because a CI runner isn't going to have all the "generated" stuff like node_modules or build directories, but when trying to run locally, being able to exclude that stuff is crucial.

I figured I should ask. Given the comment at https://github.com/dagger/dagger/issues/6155#issuecomment-1964763525.

Do these "view" / "exclude" lists apply to all directories that might be passed into the dagger call?

[wide cradle]

Thanks Kyle, I was aware of an include/exclude question but now I know exactly what it means 🙂

@heady tiger FYI there is this request for bikeshedding https://github.com/dagger/dagger/pull/6857

once that is merged it should make this a lot cleaner, if you have an opinion on that proposed solution we would love to hear about it.

[wide cradle]

I think its a bit more configurable than that, the PR I linked to describes the proposed interface a bit better.

# create a new view named cool-view
dagger config views set --name cool-view '**/*.go' '!bin/'

# use the view
dagger call fn --dir-arg /some/path:cool-view

# see the existing patterns of cool-view
dagger config views --name cool-view

# append more patterns to cool-view
dagger config views append --name cool-view '!node_modules/'

# remove some existing patterns from cool-view
dagger config views clear --name cool-view '!bin/'

# remove cool-view entirely
dagger config views clear --name cool-view

[heady tiger]

Yeah, so if Im reading this correctly... I could create a view called "motion-monorepo-local" where we would keep a list of includes and excludes than when we call a dagger function it would look like.... dagger call lint --dir-arg /motion/monorepo:motion-monorepo-local?

[wide cradle]

Yeah exactly

but the idea is you could make n views so depending on the context you may want to have different behaviors

[heady tiger]

Yeah yeah, which would be great. As long as that's all configuration in the dagger.json, that would be sweet.

Side question, how does dagger know --dir-arg is a directory that needs to be mounted as opposed to a random string that is passed into a function?

[wide cradle]

Good question, @lavish beacon is --dir-arg in this example a new built-in argument or just an example of a function that has a typed directory argument?

[heady tiger]

Yeah, looking over the docs it def seems that args are parsed in relation to the type it's given in TS. Super interesting.

[wide cradle]

For sure, I think the short answer for "how does the engine know" is based on the type in the function signature.

I am just curious if this is somehow built in as well.

[lucid snow]

exactly that's how it works. If the function argument type is Directory, then the engine has different resolvers from where those directories could be coming from.

for example, this is also valid:

dagger call container-echo --dir https://github.com/dagger/dagger.git

code that does that comes from here: https://github.com/marcosnils/dagger/blob/96c7db2c9e2ed7fbf5fe59240cd158e9c67b5355/cmd/dagger/flags.go#L197

[heady tiger]

Cool stuff. Thanks for the info! I'll keep an on the views stuff from higher up in this thread!

[brisk violet]

Where would these views be stored? Would I need to set it for each directory that I work out of?
I currently have 3 different clones of our repo, and it would also need to be configured on the CI box

[timber pewter]

The views would be configured in the target directory's dagger.json. If you're looking to import a git repo checkout without local changes, it might be more efficient to clone directly from your Dagger code. Then you don't need to worry about filtering at all

[brisk violet]

If I'm understanding you correctly, I would need a dagger.json inside of my monorepo?
Currently we have our dagger module in a separate repo.

Although, I'm not quite certian which folder you are calling the "target"

[timber pewter]

Yes in order to use views, that's the idea. By target I meant the directory being designated from the CLI and passed as argument to a function.

Note that this "views" feature is not yet merged, but is high on the priority list because it makes Functions much more practical with large monorepos

[brisk violet]

Cool. I noticed that the PR was still a work in progress. I'll keep an eye out for it as it kinda blocks us from running locally

As a side note, I really like the approach

[timber pewter]

Is passing the git repo instead of local checkout a possible stopgap for you in the meantime?

[brisk violet]

Ya that will get us around it for now.

[brisk violet]

Can we have it exclude 'node_modules' like it currently excludes **/.git, or would that be too much of a breaking change ?