31 Replies
i saw some comments in a PR
we have too many conversations, please 🧵 🙂
yeah i didnt find an existing thread and i forget there is a button in the top now to make threads
i figured since we are adding toolbox support we could at least give it the same treatment as distrobox with menus and such
so thats what i have been working on this evening, and if you spot in the last command it automatically detect if its a image or image registry 😄
only thing left now is the rhel image detection to do the login stuff. as i am not sure if its the same podman login command that @Noel used for distrobox 🙂
yes
do you think we should make
toolbox.ini point to our ublue toolbox images?
or the quay ones or just keep them rhel+fedora+ubuntu+arch only 🤔well...
please don't take this as an attack.... but I actually think the toolbox assemble stuff is a bit over-engineered...
The only thing we really needed toolbox for was RHEL and maybe Fedora toolboxes.
since the benefit with the ublue ones (at a glance from me who dont use toolbox) is that they have a latest tag so we dont need to update the registry url
That said, if it's simple enough, i'm not against it... just uncertain of the value add.
i just made it as a nice to have for those who want to use toolbox
I understand and appreciate the effort. But the original request was pretty narrow in scope... it's creeped a bit.
So, how can my comments be helpful? 🙂
I'd take them as input about keeping the toolbox "tooling" simple. That includes limiting the number of toolboxes available through it to RHEL and maybe Fedora.
also the other reason i made the assemble function is because its dead easy to update without modifying the script itself 🤣
I'm open to being challenged... but if anything I'm just sharing a perspective.
Definitely lets keep the list of images for toolbox short. We aren't trying to add all of distrobox capability to toolbox, so we shouldn't try to fit all the same image options in both.
well yeah we wanted to limit the images used for it just curious if we want the pre-defined ones to point to quay latest images for fedora? redhat ones will be the redhat access ones
oh yeah thats not the plan, if i were going to make an assemble function it was going to be a severely limited implementation especially since toolbox lacks a lot of functionality
i just liked the idea of just being able to
ujust toolbox-assemble file.ini and then assemble all the containers in it or select one to assemble in case it would be useful
how does that look?i think that looks like the right place to start
idk if there is anything equivalent to fedora:latest for toolbox without using our own image but it also serves as a nice demonstration of the ini file four our toolbox assemble
i will get to making the just commands now since the tooling is done at least for just (and it will not be expanded upon)
hey @Noel i am correct to believe you still use
podman login for the rhel images when using toolbox right?So it may not be required anymore.
RHEL is available straight through toolbox and that registry doesn't require authentication.
I looked at the container files and they are identical.
What you need to use them is a dev subscription or full subscription through Red Hat.
That is accomplished through subscription-manager.
I've found it the easiest to layer that into my image.
ok so leave that to the user then?
or shall we make the just recipe layer subscription manager if they try to make a rhel container
i think that's a task for the user
if they need subscription manager, they should be able to configure it
ok wow, this made my task way easier then
Yup!
all this code
gone
Like I said, it was debatable whether it's worth having.
KISS 🙂
Either way, it's a convenience thing. And that's what ujust is for in a lot of cases.
KISS - "Keep It Simple S(ubstitute noun starting with 's' here)"
i tell myself this often
same, except when i start overengineering things to protect from S(ubstitute noun starting with 's' here) stuff
i also try to remember... if software and open source is about freedom... i'm not trying to protect users from hurting themselves... that's the cult of safety and it leads to reduced freedom...
but... i also try to balance that with not creating tools which are deliberately difficult and likely to cause problems
lots of balancing acts and judgement calls...
oh definitively.
sometimes though you have to make a few nice to haves that are out of scope just to either standardize something or to just provide some QOL
https://github.com/ublue-os/config/pull/218
ready for review
GitHub
feat(just): add option to use toolbox instead of distrobox by Hikar...
Since toolbox and distrobox are nowhere near feature parity (and not always compatible with each other), it made more sense to provide the toolbox option as a separate recipe.
Recipes
This PR imple...
Yep. I just try to be the one who asks us to think about it... I try to not often say "no!"