On November 18, 2020, Bengt Richter <bokr@bokr.com> wrote:
E.g., (quoted from [1]), does the following mean that the guix daemon potentially could run "projects"
instead of guixbuilder* to create "Multiple isolated environments on a single host" ?
The features of Compose that make it effective are:
Multiple isolated environments on a single host
Preserve volume data when containers are created
Only recreate containers that have changed
Variables and moving a composition between environments
I love docker-compose and have used it every day. There are a bunch of workflows I use compose for that I haven't figured out how to replace with Guix yet, and I'm not in a huge hurry, but it would be great to see features that are designed to appeal to Compose users.
For example, a common thing I do with docker-compose is to provide a compose file with a service I'm working on that brings up the service with all its dependencies (eg databases, proxies, etc.) in a dev configuration, with the source code from the repository mapped into the container and live-reload enabled. That creates a "two-step" dev environment for the service: you clone the repo then run "docker-compose up."
Hashicorp has been working on Waypoint[1], a free software tool to extend that concept even further by adding deployment and release capabilities. Now you clone a repo and you have one tool to build, deploy and release the software contained therein.
I'm interested to use Guix for similar purposes, but there are a few primary obstacles in the way:
1) I don't have enough experience yet defining systems using Guix similar to what I'd define using docker-compose, and I haven't found documentation or examples yet that makes it seem within reach
2) The machines I'm deploying to run Kubernetes, not Guix System, so if I do use Guix to build a bundle for deployment its utility ends when I export to a Docker container image.
3) I collaborate with developers who use macOS and Windows and so can't easily install and use Guix.
[1] https://www.waypointproject.io/