#`dagger use ../rust --alias rust` or

1 messages · Page 1 of 1 (latest)

silent reef
#

That's what --name is for:

dagger use ../rust --name=<alias>

Which defaults to the name of the dir, so if you just used:

dagger use ../rust

Your dagger.json should have this:

{
  "dependencies": [
    {
      "name": "rust",
      "source": "../rust"
    }
  ]
}

So you can use what's in "name" with -m:

dagger -m rust call build
#

Works the same with external references, so if you do:

dagger use github.com/shykes/daggerverse/docker@v0.4.3

You'll see in your dagger.json:

{
  "dependencies": [
    {
      "name": "docker",
      "source": "github.com/shykes/daggerverse/docker@c9a80c9eac0675a53a7e052da3594207f4235988"
    }
  ],
}

Which means you can do:

dagger -m docker functions
still copper
#

Oooh

silent reef
#

You can also have a dagger init in the root of your repo, without source (without --sdk), and is just a collection of dependencies, external and/or internal, so you can use a shorthand -m in the root, to any of them.

still copper
#

I didn't realise that, that helps a lot

#

So why can't dagger functions list used modules and their functions?

silent reef
#

Like call, you need to specify which module with -m.

still copper
#

It feels like there's a bit of awkwardness to discovering functions with a project

#

because I need to tell people to look in dagger.json, get all the module aliases and then run dagger functions -m for each

#

It would be nice if dagger functions could list all of them:

Module Name             Description
rust   container-echo   Returns a container that echoes whatever string argument is provided
rust   grep-dir         Returns lines that match a pattern in the files of the provided Directory
#

Something like that, then it's obvious they can do dagger call -m rust container-echo

#

Obviously there's remote modules, I get that; but if the name exists in dagger.json; it feels like we can make discovery a little easier

silent reef
#

Initially, dagger functions listed all the functions in all objects. You'd need to know that you can only start dagger call with a function from the main object though, so now you have to chain to get the next list of functions.

#

But what you’re describing actually makes sense to me. Wdyt @slate dew?

#

Most common use case is for dependencies to be used in the source of the current module. So the first column Module would show as empty for the current module, and then you'd see other modules from the dependencies which may not make sense to run directly with -m.

So I'm wondering if there should be a flag to include dependencies (e.g., dagger functions --all), which could default to true if the current module only has dependencies and no source since the main use case here is the opposite.

still copper
#

I guess that some functions can be used directly and some only make sense as dependencies and perhaps we need a way to highlight that, such as @func(internal)

silent reef
#

It's hard to know how they're going to be used, but we've discussed the possibility of declaring a module as being a library module or a main module. That was in the context of being able to relax what host resources a module can access in some cases. And because users also seem to struggle deciding which patterns to implement because sometimes they intend it to be used in code, and other times they're crafting a CLI experience. There's lots of "utility" modules that can be used great directly in the CLI or as dependencies in code. So this remains an idea but we haven't dug into it yet (I think, see point 4 in Intertwined issues, #6229).

fair herald
still copper
#

In my mono repo, many of my services use the same stack. Terrform CDK, Grafbase, Turso, Bun, Drizzle

#

So I've built modules that handle all those common tasks and I add them as depdencies to my services

fair herald
#

Ah interesting, and you'd rather call those modules directly from the CLI than write code that integrates them into each module?

still copper
#

Yes, I don't want to write the same module for every service that has an identical pipeline

#

Moonrepo has task inheritance that solves this problem