Avatarfile

The Avatarfile documentation is still incomplete, but you can use the following example as a good reference:

---
# This is of no use... for now, but it must be there
avatarVersion: '0.18.1'

# Keep the value generated by `avatar init`, don't share it across projects.
# This value is used (among other things) to keep track of managed volumes and
# containers
projectInternalId: v2ZmtbkGuVdvGwVE

# The field shellConfig is optional, it allows you to define some settings for
# the Avatar-CLI subshell (started via `avatar shell`).
shellConfig:
  # You can define environment variables for the subshell
  env:
    SOME_ENV_VAR: 42
  # In the case of the $PATH environment variable, Avatar-CLI forbids declaring
  # it through the `env` field, but you can extend it adding multiple paths to
  # the `extraPaths` field. This can be useful if you want to access tools
  # provided by some package manager, like `npm` or `composer`, as if they were
  # installed globally.
  extraPaths:
    - ./node_modules/.bin

# In this section we declare the OCI images that we'll use in our project
images:
  # Image name
  node:
    tags:
      14-buster:
        # The runConfig block allows us to tweak our containers, to improve
        # their integration with our development environment.
        runConfig:
          # You can specify hardcoded environment variables for your containers,
          # in this example we use this to configure NPM's cache
          env:
            npm_config_cache: /caches/.npm

          # You can pass host environment variables to your containers
          envFromHost:
            - NPM_TOKEN

          # You can specify which container paths have to be mounted as volumes,
          # this is specially useful for package managers' caches
          volumes:
            /caches/.npm: {} # In most cases, we won't need to configure volumes
            /another/example:
              # Volume names are usually autogenerated, use this configuration
              # option only in case you want to share volumes accross projects
              name: exotic_volume

              # By default, the scope of a volume is "Project", allowed values
              # are "Project", "OCIImage" and "Binary".
              # This setting defines how volumes are shared between containers,
              # and has no effect if a custom volume name has been set.
              scope: Project

          # In most cases, bindings won't be necessary, and it's advisable to
          # avoid them as they difficult to share development environments with
          # other people. But, if you really need to map a container path to
          # your host filesystem, they will allow you to do so.
          bindings:
            /container/path: /host/path

      # For each image, we can declare which binaries we want to expose to our
      # project.
      binaries:
        node:
          path: node # The path can also be an absolute path

          # Although we don't do it in this example, each binary can have its
          # own `runConfig` block, and its values will override the ones defined
          # at the image tag level

        # Usually we can skip configuring the binary, we just have to list it
        npm: {}
        npx: {}
        yarn: {}

  # Image name
  rust:
    tags:
      1.45-stretch:
        binaries:
          cargo:
            path: cargo