Easy way to have multiple toolboxes for different purposes.

[emiljoha]

Is your feature request related to a problem? Please describe. My one single toolbox container becomes what I want to get away from by using an immutable desktop, a big mess.

Describe the solution you'd like A way to have multiple reproducible toolboxes for different purposes.

Describe alternatives you've considered The different toolboxes could be defined in the configuration file and point to either repository images or Containerfiles.

Additional context This would be an important feature if I would pitch the developer team I work on to start using toolbox. The IT department can manage the underlying OS and run the same thing on every computer in the company, while the developer teams can standardize within the team on a common environment matching production. But still keeping the flexibility of individual team members to make change to their setup while still making it possible to "nuke and pave" and get back to the "official" dev environment.

[pierreprinetti]

A corporate-managed ostree image can become a security nightmare (who signs the ca-cert package?), a bad practice (will IT choose my editor? and what if our customers use a different browser that what's mandated by the corp?) and overall a maintenance burden for your IT department.

In order to give your engineers a base set of common tools, you could instead reverse your design and distribute a Toolbox container image for your project. Everyone would still be using the publicly audited ostree image of your OS of choice, but they would have the choice to use your Toolbox image for development.

You can create a repo containing a Dockerfile here on Github (or your corporate git server), build it in Quay (or Docker Hub, or a private registry), and let your engineers use it.

Example Dockerfile:

FROM registry.fedoraproject.org/f34/fedora-toolbox:34

LABEL maintainer="You <you@yourcompany.example.com>"

RUN dnf install -y zsh tmux autojump-zsh fd-find ripgrep

RUN echo 'export ZDOTDIR="${XDG_CONFIG_HOME:-${HOME}/.config}/zsh"' >> /etc/zshenv

Individual engineers can then:

toolbox create -i quay.io/your-company/project-toolbox:34 project
toolbox enter project

[emiljoha]

A corporate-managed ostree image can become a security nightmare (who signs the ca-cert package?)

Not sure I follow. Are not most installations on company owned computers corporate-managed in some form or another? What would be the different from a security perspective in a immutable system?

a bad practice (will IT choose my editor? and what if our customers use a different browser that what's mandated by the corp?) and overall a maintenance burden for your IT department.

My thought was that things as editors and apps like the browser are separated from the base system with flatpaks/toolboxes/regular containers. Reducing the amount diversity in the base operating system of the company computers I would think instead reduces the maintenance burden on the IT department.

Maybe there is something that makes this impossible that I am missing

In order to give your engineers a base set of common tools, you could instead reverse your design and distribute a Toolbox container image for your project. Everyone would still be using the publicly audited ostree image of your OS of choice, but they would have the choice to use your Toolbox image for development.

That could absolutely work!

Such a Toolbox image would probably be something that an (if existing) dev-ops team could provide making the dev environment similar to the deployment environment if the team chooses to use it.

You can create a repo containing a Dockerfile here on Github (or your corporate git server), build it in Quay (or Docker Hub, or a private registry), and let your engineers use it.

Thanks for the example, that is really cool! That is something I should consider doing for my own personal dev environment. It both documents and makes the environment reproducible.

However, this does not help me split up and get away from one single big toolbox, it does help with making that toolbox less messy though.

I still see potential value in having one toolbox for each of my many projects that all depend on some "base toolbox". But maybe that is out of scope for the "toolbox" tool.

Thinking if I could create something that wraps around toolbox and creates the necessary images and gives the necessary arguments to get this functionality. toolbox-organizer :thinking:

[pierreprinetti]

Are not most installations on company owned computers corporate-managed in some form or another? What would be the different from a security perspective in a immutable system?

Right. No difference. Mine was just a general consideration on corporate-managed computers.

having one toolbox for each of my many projects that all depend on some "base toolbox". But maybe that is out of scope for the "toolbox" tool.

In my understanding, that's exactly what Toolbox is about :) I have roughly one toolbox container per project, and they all happen to be built on the same base image (which in turn, is based on the standard Fedora image):

toolbox create -i quay.io/your-username/project-toolbox:34 project1
toolbox create -i quay.io/your-username/project-toolbox:34 project2
toolbox create -i quay.io/your-username/project-toolbox:34 project3

If you find that useful, you can also create per-project Dockerfiles FROM quay.io/your-username/project-toolbox:34, that add the libraries or toolchains for that particular project.

[emiljoha]

Right. No difference. Mine was just a general consideration on corporate-managed computers.

Sure, there is an argument that corporate-managed computers should be banished. In my current corporate environment that is such a foreign idea that even in my daydreaming around moving development from macs to Linux and using toolboxes, that fundamental assumption about who manages the OS was never even questioned in my mind...

I have roughly one toolbox container per project, and they all happen to be built on the same base image (which in turn, is based on the standard Fedora image):

This is exactly what I want!

Tried this out and it seems like one needs to add --container in front of the container name, otherwise it becomes the command to run.

toolbox create -i quay.io/your-username/project-toolbox:34 -c project1

This is a really cool feature that IMO is way under-advertised. Maybe we could add something to the README about how to use toolbox in this cool way?

[emiljoha]

As I wrote in the PR, realized that it seems like the toolbox utility I am using is this one `https://github.com/kubic-project/microos-toolbox The two utilities are very similar so I still think that this type of functionality should be better advertised (in both) so I will leave my PR up if there is some interest but close this issue.

Thank you @pierreprinetti for your help!

PS: This is probably only true for the micro os version

Tried this out and it seems like one needs to add --container in front of the container name, otherwise it becomes the command to run.