Dependencies

When creating a Dagger module, there are two types of dependencies you will encounter:

• Dependencies on other Dagger modules
• Dependencies on third-party packages or modules from your programming language's ecosystem

Dependencies on Dagger modules

Dagger modules are shareable and reusable. You can call Dagger Functions from any Dagger module in your own Dagger module simply by adding it as a module dependency with dagger install, as in the following example:

dagger install github.com/shykes/daggerverse/hello@v0.3.0

This module will be added to your dagger.json:

...
"dependencies": [
  {
    "name": "hello",
    "source": "github.com/shykes/daggerverse/hello@54d86c6002d954167796e41886a47c47d95a626d"
  }
]

When you add a dependency to your module with dagger install, the dependent module will be added to the code-generation routines and can be accessed from your own module's code.

The entrypoint to accessing dependent modules from your own module's code is dag, the Dagger client, which is pre-initialized. It contains all the core types (like Container, Directory, etc.), as well as bindings to any dependencies your module has declared.

Here is an example of accessing the installed hello module from your own module's code:

Go

func (m *MyModule) Greeting(ctx context.Context) (string, error) {
  return dag.Hello().Hello(ctx)
}

Python

@function
async def greeting(self) -> str:
  return await dag.hello().hello()

TypeScript

@func()
async greeting(): Promise<string> {
  return await dag.hello().hello()
}

You can also use local modules as dependencies. However, they must be stored in a sub-directory of your module. For example:

dagger install ./path/to/module

Dependencies on third-party packages

Dagger Functions are just regular code, written in your usual programming language. One of the key advantages of this approach is that it opens up access to your language's existing ecosystem of packages or modules. You can easily add and use these packages/modules as dependencies in your Dagger module via your language's package manager.

Go

To add a Go dependency, add it to your go.mod file using go get. For example:

go get github.com/spf13/cobra

Python

To add a Python package, add it to your pyproject.toml file using your chosen package manager. For example:

uv

uv add requests

poetry

poetry add requests

uv pip

Add the dependency manually to pyproject.toml:

[project]
dependencies = [
    "requirements>=2.32.3",
]

Then install into your virtual environment:

uv pip install -e ./sdk -e .

note

There's no need to activate the virtual environment before uv pip install, but it does need to exist.

pip

Add the dependency manually to pyproject.toml:

[project]
dependencies = [
    "requirements>=2.32.3",
]

Then install into your virtual environment:

python -m pip install -e ./sdk -e .

tip

If you haven't setup your local environment yet, see IDE Integration.

note

Third-party dependencies are managed in the same way as any normal Python project. The only limitation is in "pinning" the dependencies. Currently, Dagger can install directly from a uv.lock file, or a pip-tools compatible requirements.lock file (notice .lock extension, not .txt). See Language-native packaging for more information.

TypeScript

To add a TypeScript dependency, add it to the package.json file using your favorite package manager. For example:

npm install pm2

Pinning a specific dependency version or adding local dependencies are supported, in the same way as any Node.js project.

TypeScript can manage dependencies using multiple package managers. The Node.js runtime supports npm, pnpm and yarn. The Bun runtime supports bun.

By default, the TypeScript SDK executes functions using the Node.js runtime with yarn v1.22.22, but you can configure an alternative package manager or version in your Dagger module's package.json file by setting the packageManager property.

Npm

Set the packageManager property to npm to use the npm package manager. You can also set a specific version with a suffix, as shown below:

  "packageManager": "npm@10.8.2"

If no version is specified, npm@10.7.0 is used by default.

Yarn

Set the packageManager property to yarn to use the Yarn package manager. You can also set a specific version with a suffix, as shown below:

  "packageManager": "yarn@1.22.21"

If no version is specified, yarn@1.22.22 is used by default.

If you use Yarn 3.0 or above, the TypeScript SDK will also generate a .yarnrc.yml file in your module's root directory. This file is used to configure the Yarn package manager linker to node_modules, which is required to correctly resolve @dagger.io/dagger as local dependencies of your module.

nodeLinker: node-modules

Pnpm

Set the packageManager property to pnpm to use the Pnpm package manager. You can also set a specific version with a suffix, e.g.:

  "packageManager": "pnpm@9.9"

If no version is specified, pnpm@8.15.4 is used.

The TypeScript SDK will also generate a pnpm-workspace.yml file in your module's root directory. This file is used to configure the Pnpm package manager, which is required to correctly resolve @dagger.io/dagger as local dependencies of your module.

packages:
  - './sdk'

Bun

warning

Bun runtime support is still experimental. Unexpected results may occur in some cases.

Setting the runtime property to bun will use the Bun runtime and its package manager. You do not need to set the packageManager field explicitly. Here is an example:

  "dagger": {
    "runtime": "bun"
  }

Automatic detection

When a package manager is not explicitly defined within the package.json file, Dagger automatically identifies the appropriate package manager by examining the project's lock files inside the project's .dagger directory.

• If Dagger finds any of the following lock files : package-lock.json, yarn.lock, or pnpm-lock.yaml, it automatically selects the corresponding package manager with a predefined default version: npm@10.7.0, yarn@1.22.22 or pnpm@8.15.4.
• If none of the above mentioned lock files are present, but a bun.lockb file is present, Dagger will choose bun as the runtime and package manager with a predefined default version: bun@1.0.11.
• yarn@1.22.22 is the last default, when nothing mentioned above applies.

warning

This behavior however should be considered a sensible fallback, and not as an explicit configuration. Since this default can change, we encourage you to configure a package manager explicitly.