Open noelmiller opened 6 months ago
well i agree on removal from our helper things lowers tech debt but honestly lowers workload for those that do the work which is always good
+1 on this, we're already recommending distrobox, this just confuses people.
but i also think we can at this point depricate them and remove when they break for users sake
Very quick thoughts: We added this for UBi. The toolbox assemble basically only makes a ubi container and a fedora container.
I think those are already apart of the toolbox command directly via the -d flag or whatever it is for distro.
Besides ubi (which distrobox can make but doesn't have the mount for rhel licenses) there isn't much of an add for toolbox. It is fast though.....
Very quick thoughts: We added this for UBi. The toolbox assemble basically only makes a ubi container and a fedora container.
I think those are already apart of the toolbox command directly via the -d flag or whatever it is for distro.
Besides ubi (which distrobox can make but doesn't have the mount for rhel licenses) there isn't much of an add for toolbox. It is fast though.....
This is the only reason they were added, only for rhel ubi, nothing else and it was released as-is (meaning all we do is bump the rhel version in the ini file when a new rhel version releases, this was why i made the assemble function use the same ini format as the distrobox.ini but separate the files)
What we can do though is remove the toolbox-new recipe from just and only keep the toolbox-assemble and slap in that this is only meant for rhel containers, use distrobox for everything else.
Unless the plan is to just go "you're a redhat person, you know how to use toolbox, use that if you need a rhel container"?
I spent a couple days looking at the source and figuring out what the hell is going on here. I'm not a huge fan of distrobox/toolbox/toolbx in the first place as it kind of breaks the paradigm of what you'd expect out of a container (a lightweight VM). Like I don't know what problem it is trying to solve that dotfiles and overlayfs or something similar can't achieve. I came around to the idea but I still think x-boxes are just really confusing unless you're really into the world of simply distro hopping. Like I want an immutable base system and a container I can just add random shit to and then destroy it and it goes all away. Or a container that specific to the requirements of whatever project I'm on. Like usually I have a strange build process due to external constraints. So say something like bun works really well even if it has faults, I can pre-commit and generate the standard the client is looking for (npm, node_modules, etc.).
Or I'm fooling around and install the latest thing I heard on hackernews but don't want to think about if it'll screws things up.
So like as a developer-ish that pretends he doesn't do sales or upper management stuff, I use containers to fool around in and are basically ephemeral or I do it because the team uses Windows or something graphical and I don't want to screw up their workflow.
The idea that you're basically just using a different shell seems like a solved problem with dotfiles. I learned to lock down distroboxes and take advantage of the host without letting it accidentally screw up the host. I don't get why you'd use it for anything but creating a hardened environment that makes it easy to make changes you can get rid of or make an environment specific to a team setup while still doing our own things.
I say nuke it. If someone wants a toolbox for some specific reason create their own variation. Otherwise the minor differences are confusing.
I went ahead and deprecated toobox in bluefin for 40+: https://github.com/ublue-os/bluefin/pull/1347
I went ahead and deprecated toobox in bluefin for 40+: ublue-os/bluefin#1347
I thought this issue was leaving toolbox present, but removing it from the Just scripts? Hesitant to remove it altogether as it's a breaking change.
I thought this issue was leaving toolbox present, but removing it from the Just scripts?
I think it is what happened eventually, right ?
Problem
We currently are pushing folks to use Distrobox as a method for running containers and installing software. Toolbox lacks features in comparison to Distrobox. Managing 2 different tools that do similar things is creating tech debt we don't need.
Solution
Remove Toolbox just scripts. We can still leave it in the main image and if there is demand to add it back, we can re-add it.
Discord Thread
https://discord.com/channels/1072614816579063828/1239747942026575872