We are excited to announce the next version of vagga, the containerization tool that makes setting up development environments easy and fun.

We are trying to make the delay between releases shorter. This version comes just two months after previous. It has few stable features, but due to short release cycle, it’s full of experimental features which enhance vagga’s functionality a lot. Still experimental features may be messed up in future, so use at your risk.

CacheDir Volume

Previously there was a clear separation between directories that can be used during the build and volumes available when running a command.

The CacheDir volume bridges the gap. It’s useful when your package manager wants to access package cache after installation during command lifecycle, for example, to find out updated versions of the packages.



Example for maven:

setup:

# ...

- !CacheDirs

/root/.m2/repository: maven-cache

# ...

volumes:

/root/.m2/reposiory: !CacheDir maven-cache

Unlike !Persistent volume !CacheDir is shared between projects if you use shared cache-dir setting, so this volume might be used to share build cache between projects. For example, here is how you can share cargo’s cache:

cargo: !Command

container: rust

environ: { HOME: /root }

volumes: { /root/.cargo: !CacheDir cargo }

run: [cargo]

Waiting for Multiple Processes

Previously vagga had a single supervision mode (few others were dropped since 0.2), that is: fail whole process tree when any single process fails or exits.

This release brings wait-all-successful mode, which runs a family of processes and if no process has failed with non-zero exit code it waits for others to finish. I. e., it’s suitable to run multiple tasks in

parallel, waiting for all of them to finish.

For example, to run data migrations on both MongoDB and Postgres, we might run the following imaginary command:

migrate: !Supervise

mode: wait-all-successful

children:

postgres: !Command

container: py

run: [alembic, -n, alembic:dev, upgrade, head]

mongo: !Command

container: py

run: [nomad, apply, -a]

Experimental: Symlinks to Vagga

Have you ever wanted to run flake8 to check your python code? Unfortunately, flake8 requires a specific version of python to run correctly. This is where vagga helps. Running vagga flake8 was fun since the beginning of the times. But many IDE’s and other tools require a single binary as code linter for whatever technical reason.

Even more wouldn’t it be cool if you can have a flake8 utility in the system that always looks at the right vagga.yaml?

Now you can configure a symlink-name property:

And if vagga is run from a symlink named flake8 it will run just this command. There is a command-line to make symlinks in known places:

vagga _update_symlinks

The above makes symlinks in $HOME/.vagga/cmd and projectdir/.vagga/.cmd . But you can also make a symlink in /usr/local/bin or any other system location. And you can point your editor to ~/.vagga/cmd or specify project-dir/.vagga/.cmd in your project settings to setup just the editor or an IDE.

The reason why the feature is experimental is that we’re not certain how to handle working directory of the command and how to translate paths from /work into project directory outside the container. Please discuss any issues you have on github.

Experimental: Mixins

As promised in previous release notes we expand our composition tools even more. This release brings mixins to place.

The basic idea of mixins is that you put together multiple vagga files:

mixins:

- vagga/postgres.yaml

- vagga/app.yaml

- vagga/deployment.yaml

If the text above is put into your vagga.yaml, t he containers and commands from all of the listed files are available to run. At a glance it’s superior to !*Includes in one small aspect: both commands and containers included are in in the same file. It not just helps to organize configs, but also allows to alias things between commands and containers (remember each included or mixed-in config is a valid YAML, including all of its anchors)

But it’s not enough. The power of mixins is unleashed when you put together a vagga command that generates some mixin. To make it work flawlessly, we skip invalid or absent mixin files, which makes other vagga commands work, this, in turn, allows user to (re)build appropriate mixin by running a vagga command. For example, you may have a command which generates a config for deployment containers:

mixins:

- generated/deploy.yaml

commands:

gen-deploy-configs: !Command

run: [generator.sh]

container: generator-container

And because latter mixins override former you can have a fallback in the case some config can’t be read (and fallback can probably regenerate invalid config):

mixins:

- vagga/generator.yaml

- vagga/fallback-containers.yaml

- generated/containers.yaml

The thing that makes this functionality experimental is that we’re not sure whether people will make deep nesting of mixins and how confusing it would be to read. We also have doubts if we had set up overriding as expected and that ignoring errors is fine. Surely we have a list of containers with source files in case you ever get confused:

> vagga _list --containers -v

alpine

(from "/project/vagga.yaml")

postgres

(from "/project/mixins/postgres.yaml")

> vagga _list -v

run Run the application

(from "/project/vagga.yaml")

make Build the application

(from "/project/vagga.yaml")

postgres Run postgres database

(from "/project/mixins/postgres.yaml")

pgcli Run postgres command-line utility

(from "/project/mixins/postgres.yaml")

Experimental: Capsule Commands

This is a very expert feature. The capsule is an intermediate container we use to power our build process. The key feature is: you can run a script in the capsule that decides which containers to build and which commands to run inside. Using the tool we can regenerate some parts of the config and build a fresh container without leaving the vagga command. The feature we have never had before (except running a bash script outside of vagga).

Overall this feature should not be considered generally available and you should not use it. It’s released mainly for vagga developers and early adopters to work on deployment tools and other higher-level tools on top of vagga. But if you feel adventurous there is some documentation.

Smaller Features

We’re now shipping zsh completion in addition to bash completion

Added _base_dir and _relative_work_dir subcommands for scripts

and subcommands for scripts We included indexing containers after build using dir-signature crate, this isn’t useful as of yet, but we’re going to use it to optimize space used by multiple containers in future releases of vagga

Contributors

Release 0.7.1 consists of more that 90 commits from 4 contributors. Thank you!