Jcc @M2 @Robert (p5) @jeefy
Jok, so if I had a time machine - I would go back and do this as the first solution. And also the actual reason is this feature is well beyond my skill to implement.
JSo thanks @M2 for leading this. I have some thoughts as to how we ended here. (If it works in practice that is, hah!)
JAlright so the reason this is part of The Final Shape is that means the entire toolbox containers can be rebuilt from scratch, as reproduceable as possible. It's like the first time you tried docker and didn't know about volume mounts. Then you do stuff and when the container gets destroyed you get mad that you lost all that data. Then you realize you know enough to get into trouble but not the conceptual understanding of containers yet
JAnd I think part of the reason we started is toolbox encourages you to use it to replace your CLI/dnf experience. Which makes a lot of sense.
JSo, I think it ends up encouraging pets. But most of us who work in containers don't do it that way, we declare instead.
JThis was excacerbated every time
podmanSo quadlets presented us with an opportunity to make the toolboxes disposable and split out the config/data. Destroy them all, I can snap my fingers and they come up perfect. That's what we're shooting for because it's the correct way.
CThat sounds useful
JPros have it all automated anyway right, they either have their own config management tool like ansible that sets it all up for them anyway, we build ours in github, etc.
CRight
JThen that removes the possibility of you being like "why does my computer never remember the packages I install", which would be a terrible outcome
Jso you just get it fresh, every day, built from scratch
Jand it removes a great deal of mirror issues people have since ghcr.io's mirror capacity is huge.
Jand you don't need to care about how slow dnf is anymore since it's just getting oci layers anyway, just like the OS.
Jand if you've got a homelab now your OS and workflow can be cached, served locally, etc. It ties everything together.
Jyou'll of course still use dnf manually, it'll just be for "oh let me try this thing" and then if you wanna keep it, you can add it to the file. Then tomorrow the container is destroyed and rebuilt but you still have it, it's just in the container now.
CTwo main concerns:
- making that config management as fast and seamless as possible
- cleaning up dependencies from the config
- making that config management as fast and seamless as possible
- cleaning up dependencies from the config
J1) is what we just finished, that's how I came to the conclusions I posted about
Jconfused on #2, which dependencies and in what config? The list of packages?
CIt does sound like the more proper way to implement sustainable containers, but it is competing with "dnf install xyz" for ease and simplicity - all of the people willing and able to maintain a higher level of skill and effort already do. What is the just-finished solution?
JThe just finished solution (tldr of what I said above), they get rebuilt every day from scratch, the pet container is destroyed unless you declare the package in the file.
JSorry I am extra rambly tonight
CAh, I mean, what is the solution to: making it frictionless to declare packages in that file and remove them, which takes nearly zero skill or effort for someone who has never used declarative package management and is only comfortable with a traditional package manager? Rebuilding containers and separating temporary additions from permanent configs is clean, but it is an "MIT approach" (https://www.dreamsongs.com/RiseOfWorseIsBetter.html) which, historically, does not catch on. The people who already use Ansible and such, as you said, already do this - what it needs to achieve for wider adoption is parity with traditional package managers for ease, speed, and convenience of use, as well as ease of learning, which Ansible absolutely does not achieve
Jit's a text file, wanna see mine?
CYes
Joh, we put the initial one in the template, heh:
CSo - dependencies are cleaned up by rebuilding without the packages which pull them in?
Jif you mean "do you need to care about dependencies", it uses the same package manager. It'll pull in what you need by default.
CI wanted to double check that one of the reasons for this is to eliminate the need for a dependency solver when removing packages because the containers are just rebuilt from the ground up with the minimum of what they need
Jno, the problem isn't package dependency, it's the fact that you've created a pet container
Jwhich is an anti pattern
Jbecause when the container goes away all the packages you installed are gone, and that sucks
CSame thing, the way I was referring to it
CI was confirming that detail about dependencies as a prelude to my main thought on that config file
CIf dependencies are managed, which it looks like they cleanly are, and all of the logic is outside of the config file so the config basically boils down to the one line of
#additional_packages="ansible lynx chromium neofetch cmus"Then it should be trivial to write a dynamic command line utility to manage that one line
Jyeah
Jsure
Jhowever you interact with that file is whatever tools people use
Jtechnically you could build the thing with nix if you wanted to
Jlike, however you wanna UX it, sure
CIt's a small detail which doesn't actually impact how the thing works, but if you want people to adopt the correct pattern, it has to be frictionless compared to what they are currently using, as well as providing significant upsides.
MNote if you want to to use the assemble file, you won't use the quadlet.
You can put the assemble files items into the distrobox quadlet but it's inside the Exec line.
You can put the assemble files items into the distrobox quadlet but it's inside the Exec line.
CUX statistically and materially impacts how well something actually functions, when humans are involved. Apple's UX is measurably fundamentally terrible and anti-user, but for several interesting reasons, the simple factor that it is visually appealing to a certain subculture makes it more usable and functional than it should be
CAnd software engineers never know or realize that because it's studied and taught exclusively in industrial engineering
CIt's a brilliant piece of software engineering to streamline that user-facing declarative config file down to a single line of packages in one string, because even I can write the utility I think that needs to provide UX people will latch onto
MNote that additional packages line will require the Internet to use.
CI like this pattern and appreciate that you brought it to my attention. I would like to learn more about it and will think about prototyping that configuration tool. I think it would just be a shell script with two args and one elif/switch statement with three options
