Functions

Dagger Functions are regular code, written in a supported programming language, and running in containers. Dagger Functions let you encapsulate common operations or workflows into discrete units with clear inputs and outputs.

Here's an example of a simple Dagger Function:

from dagger import function, object_type


@object_type
class MyModule:
    @function
    def hello(self) -> str:
        return "Hello, world"

Here is an example call for this Dagger Function:

dagger call hello

The result will be:

Hello, world

Here's an example of a more complex Dagger Function, which calls a remote API method:

from dagger import dag, function, object_type


@object_type
class MyModule:
    @function
    async def get_user(self) -> str:
        return await (
            dag.container()
            .from_("alpine:latest")
            .with_exec(["apk", "add", "curl"])
            .with_exec(["apk", "add", "jq"])
            .with_exec(
                ["sh", "-c", "curl https://randomuser.me/api/ | jq .results[0].name"]
            )
            .stdout()
        )

Here is an example call for this Dagger Function:

dagger call get-user

The result will look something like this:

{
  "title": "Mrs",
  "first": "Beatrice",
  "last": "Lavigne"
}

Class methods

Dagger Functions are implemented as @dagger.function decorated methods, of a @dagger.object_type decorated class.

It's possible for a module to implement multiple classes (object types), but the first one needs to have a name that matches the module's name, in PascalCase. This object is sometimes referred to as the main object.

For example, for a module initialized with dagger init --name=my-module, the main object needs to be named MyModule.

Arguments

Dagger Functions, just like regular functions, can accept arguments. In addition to basic types (string, boolean, integer, arrays...), Dagger also defines powerful core types which functions can use for their arguments, such as Directory, Container, Service, Secret, and many more.

Here's an example of modifying the previous Dagger Function to accept a string argument:

from dagger import dag, function, object_type


@object_type
class MyModule:
    @function
    async def get_user(self, gender: str) -> str:
        return await (
            dag.container()
            .from_("alpine:latest")
            .with_exec(["apk", "add", "curl"])
            .with_exec(["apk", "add", "jq"])
            .with_exec(
                [
                    "sh",
                    "-c",
                    f"curl https://randomuser.me/api/?gender={gender} | jq .results[0].name",
                ]
            )
            .stdout()
        )

Here is an example call for this Dagger Function:

dagger call get-user --gender=male

The result will look something like this:

{
  "title": "Mr",
  "first": "Hans-Werner",
  "last": "Thielen"
}

Here's an example of a Dagger Function that accepts a Directory as argument:

import dagger
from dagger import dag, function, object_type


@object_type
class MyModule:
    @function
    async def tree(self, src: dagger.Directory, depth: str) -> str:
        return await (
            dag.container()
            .from_("alpine:latest")
            .with_mounted_directory("/mnt", src)
            .with_workdir("/mnt")
            .with_exec(["apk", "add", "tree"])
            .with_exec(["tree", "-L", depth])
            .stdout()
        )

Here is an example call for this Dagger Function:

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

The result will look like this:

.
├── LICENSE
├── dagger
└── dagger.json

2 directories, 2 files

You can also pass a remote Git reference, and the Dagger CLI will convert it to a Directory referencing the contents of that repository. Here is an example call that lists the source code for the Dagger CLI, from the main branch of the Dagger GitHub repository:

dagger call tree --src=https://github.com/dagger/dagger#main:cmd/dagger --depth=1

The result will be the same file listing as this GitHub page:

.
├── call.go
├── cloud.go
├── debug.go
├── engine.go
├── exec_nonunix.go
├── exec_unix.go
├── flags.go
├── functions.go
├── gen.go
├── licenses.go
├── listen.go
├── log.go
├── main.go
├── module.go
├── module_test.go
├── query.go
├── run.go
├── session.go
├── shell.go
└── version.go

1 directory, 20 files

note

When calling a Dagger Function from the CLI, its arguments are exposed as command-line flags. How the flag is interpreted depends on the argument type.

Optional arguments

Function arguments can be marked as optional. In this case, the Dagger CLI will not display an error if the argument is omitted in the function call.

Here's an example of a Dagger Function with an optional argument:

from dagger import function, object_type


@object_type
class MyModule:
    @function
    def hello(self, name: str | None) -> str:
        if name is None:
            name = "world"
        return f"Hello, {name}"

Here is an example call for this Dagger Function, with the optional argument:

dagger call hello --name=John

The result will look like this:

Hello, John

Here is an example call for this Dagger Function, without the optional argument:

dagger call hello

The result will look like this:

Hello, world

note

The API considers any type that accepts a None value to be optional. Thus, if the name argument is omitted from an API request, it will be set to None automatically.

However, when used directly from Python code, it's in fact a required argument since it has no default value. In this context, the term "optional" is the same concept as the older typing.Optional[X] annotation for a type that allows the None value.

Default values

Function arguments can define a default value if no value is supplied for them.

Here's an example of a Dagger Function with a default value for an argument:

from dagger import function, object_type


@object_type
class MyModule:
    @function
    def hello(self, name: str = "world") -> str:
        return f"Hello, {name}"

Here is an example call for this Dagger Function, without the required argument:

dagger call hello

The result will look like this:

Hello, world

tip

For consistency between Python and the API, choose to always set optionals with a default value, even if it's:

name: str | None = None

The above is in fact necessary if the default value needs to be set from the function body instead of the signature (dynamic, complex or a mutable value).

Return values

Not only can Dagger Functions use Dagger's core types in their arguments; they can use them in their return value as well.

This opens powerful applications to Dagger Functions. For example, a Dagger Function that builds binaries could take a directory as argument (the source code) and return another directory (containing binaries) or a container image (with the binaries included).

Here's an example of a Dagger Function that accepts a Directory containing a Go application's source code as input, compiles it into a binary, and returns a Container with the binary:

import dagger
from dagger import dag, function, object_type


@object_type
class MyModule:
    @function
    def build(self, source: dagger.Directory, arch: str, os: str) -> dagger.Container:
        dir_ = (
            dag.container()
            .from_("golang:1.21")
            .with_mounted_directory("/src", source)
            .with_workdir("/src")
            .with_env_variable("GOARCH", arch)
            .with_env_variable("GOOS", os)
            .with_env_variable("CGO_ENABLED", "0")
            .with_exec(["go", "build", "-o", "build/"])
            .directory("/src/build")
        )
        return (
            dag.container()
            .from_("alpine:latest")
            .with_directory("/usr/local/bin", dir_)
        )

Here is an example call for this Dagger Function:

dagger call build --source=https://github.com/golang/example/#master:hello --os=linux --arch=amd64 terminal

This example chains two functions calls:

a call to Build(), which builds a Go application from a remote GitHub repository and returns a Container with the compiled binary;
a call to Terminal(), which opens an interactive terminal session with the Container returned by the previous function.

The result will be an interactive terminal session with the built container, which you can use to validate the compiled Go binary:

/ # cd /usr/local/bin
/usr/local/bin # ls
hello
/usr/local/bin # ./hello
Hello, world!
/usr/local/bin #

Type annotations

Even though the Python runtime doesn’t enforce type annotations at runtime, it’s important to define them with Dagger Functions. The Python SDK needs the typing information at runtime to correctly report to the API. It can’t rely on type inference, which is only possible for external static type checkers.

If a function doesn’t have a return type annotation, it’ll be declared as None, which translates to the dagger.Void type in the API:

@function
def hello(self):
    return "Hello world!"

# Error: cannot convert string to Void

It’s fine however, when no value actually needs to be returned:

@function
def hello(self):
    ...
    # no return

Functions

Class methods​

Arguments​

Optional arguments​

Default values​

Return values​

Type annotations​

Class methods

Arguments

Optional arguments

Default values

Return values

Type annotations