Looking for guidance in building a "blingbox" from boxkit

I’m a newbie to immutable OSes, and trying to give Bluefin a spin. My goal is to have flatpaks for my GUIs, and then have my entire personalized terminal experience in a single, custom-made boxkit container (similar to the sentiment in Making the most out of distrobox and toolbx)

One thing that is tripping me up is: I would like to have some rust utilities available and installed via cargo, such that they are in $HOME/.cargo/bin. Sure, I could do this on the host, too, but again, the goal is to have everything in my personal pet container. (I also somewhat hope that if the homedir is shared, setting them up in my container gets me them on my host for free.)

How can I accomplish this such that I can build my container, have it install these rust utillities via cargo, and then have then “just work” once I enter the distrobox? For example, if I simply install cargo and cargo install something in the Containerfile, I see they are installing to /root/.cargo/bin, which I imagine will not map to my $HOME when the time comes.

Could someone give some guidance here?

I’d either investigate the cargo install --root option and see if you can just install them into the container at build time (so they come along with the container), or you could bind mount the ~.cargo/bin directory but you’d still have to set the tools up in the container.

Could you perhaps give an example of mounting .cargo/bin? I could adopt the method of installing in the container if it means I get the nice sharing of these tools between host and distrobox.

Here’s how we do it with homebrew: toolboxes/systemd/bluefin-cli/bluefin-cli-distrobox.ini at b440a2d631fdce94208cfa09939c61553fa0f348 · ublue-os/toolboxes · GitHub

Similar line in the incus container: toolboxes/apps/incus/distrobox.ini at b440a2d631fdce94208cfa09939c61553fa0f348 · ublue-os/toolboxes · GitHub

I see, thank you! These look like distrobox-assemble INIs? Is that the recommended way to use these personalized boxkits?

Yeah, or you could manage them via a quadlet service if you want to go full on:

Our Examples:

Docs:
https://docs.podman.io/en/latest/markdown/podman-systemd.unit.5.html

After you get it up and running you can export the service unit, it’s pretty slick ^^^

Apologies, two more naive questions for you. Thanks for your time.

  1. If I set my pet container up with quadlet, will I lose persistence? E.g., I see the discussion in Builtin fedora-toolbox and unbuntu-toolbox persistence and I assumed that I should not use quadlet, since it may destroy and recreate things.
  2. If I think about mounting the volume more, I’m actually under the impression I don’t need to? i.e., It would be mounting $HOME/.cargo/bin, but I actually think $HOME is mounted automatically, so I do not actually need to add any volume here. Is that correct?

We set up our quadlets to be ephemeral, but if everything is in the container destroying and recreating it shouldn’t be a huge deal.

Depending on what you want you may or may not want to mount the cargo bin, but then you’d have to copy things into that directory on first set up on a new host.

We set up our quadlets to be ephemeral, but if everything is in the container destroying and recreating it shouldn’t be a huge deal.

Hmm, so in my head, I was imagining a workflow where I have my GUIs on the host via flatpak (e.g., web browser, etc.). But then I spend essentially the entire rest of the time within my dev distrobox container. With data in my $HOME, working as if I was just using a host directly.

Does this workflow not work if the containers are ephemeral?

One thing I see is toolboxes/quadlets/fedora-toolbox/fedora-distrobox-quadlet.container at b440a2d631fdce94208cfa09939c61553fa0f348 · ublue-os/toolboxes · GitHub, it seems like if I wanted to do this, I would not want rslave mode, instead using shared for the /var/home/%u and %h volumes?

Is my plan a bad idea?

Should work fine, all you need to do is set the container as your default one in the terminal profile so it auto-opens into it each time and you should be set!

After fiddling for a couple hours, I can confirm this is working well with the quadlet, and frankly, is pretty awesome.

Appreciate the help, @j0rge, thanks!

1 Like

This sounds pretty awesome @lukehsiao !

Do you have a repo somewhere we can look up, or a blog post about this?

I would like to try and replicate some of this for myself. If I’m not mistaken there’s not even anything Bluefin specific in your final CLI container, right? You can run it on other distros too?

Do you have a repo somewhere we can look up, or a blog post about this?

Mmm, it is WIP. In the spirit of transparency, happy to share it in its WIP state (the boxkit is here: omakase-bluefin/toolbox at main · lukehsiao/omakase-bluefin · GitHub, combined with dotfiles here: dotfiles/private_dot_config/containers/systemd/dev-toolbox.container at 0c97672f91c1355c1e059a0af7ee66264d92f985 · lukehsiao/dotfiles · GitHub) (sorry, I changed the image name this norming, but haven’t update the quadlet file yet).

But I am hoping to build up an omakub-style “opinionated” setup for myself in that first repository over the next few weeks. Thus far I’ve just got proof it works, now working to automate the rest. Likely will write a blog post once it’s ready, so if anyone reads this before then…know it’s very WIP. Critique and feedback welcome!

I would like to try and replicate some of this for myself. If I’m not mistaken there’s not even anything Bluefin specific in your final CLI container, right? You can run it on other distros too?

That’s right, though I suppose it is “distrobox”-specific to some sense. I also opted for not the cargo install --root option. So, instead, I launch the container the first time, run just install-core (dotfiles/dot_justfile at 0c97672f91c1355c1e059a0af7ee66264d92f985 · lukehsiao/dotfiles · GitHub) and all those end up in the homedir shared between host and VM so all those tools are available both places.

Again, still very early exploration, but hoping to find some time the next few weeks to move everything into that omakase-bluefin repo, including config defaults, flatpak installs, gnome extensions (e.g,. PaperWM), etc. The goal is a one-line installer for a fresh Bluefin to exactly what I want on my machine.

Blog post here: Omakase Bluefin: An Omakase Developer Setup for Project Bluefin

2 Likes

That’s some nice work indeed!