Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Proposal: Remove Toolbox from Just #276

Open
noelmiller opened this issue May 14, 2024 · 9 comments
Open

Proposal: Remove Toolbox from Just #276

noelmiller opened this issue May 14, 2024 · 9 comments
Labels

Comments

@noelmiller
Copy link
Member

noelmiller commented May 14, 2024

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

@bigpod98
Copy link
Member

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

@castrojo
Copy link
Member

+1 on this, we're already recommending distrobox, this just confuses people.

@bigpod98
Copy link
Member

but i also think we can at this point depricate them and remove when they break for users sake

@m2Giles
Copy link
Member

m2Giles commented May 14, 2024

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.....

@HikariKnight
Copy link
Member

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"?

@geoffreysmith
Copy link

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.

@castrojo
Copy link
Member

I went ahead and deprecated toobox in bluefin for 40+: ublue-os/bluefin#1347

@p5
Copy link
Member

p5 commented May 25, 2024

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.

@Malix-Labs
Copy link
Contributor

I thought this issue was leaving toolbox present, but removing it from the Just scripts?

I think it is what happened eventually, right ?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

8 participants