I made my just script, it’s all working on my custom image and that’s great.
But given that it depends on the justfile importing all the just scripts, I was wondering if I did it correctly. I noticed there was this line in the justfile:
import? "/usr/share/ublue-os/just/60-custom.just"
So I figured I’d make a justfile called 60-custom.just, as I think that’s what that line is for “Import it if file exists” kinda thing - so we can make our own scripts. Is that correct?
Otherwise I would have to make changes to the justfile and then any changes Ublue makes won’t be reflected.
Can I just confirm that’s how I am supposed to do this?
When I first started using bluefin I noticed the same things myself.
Where I landed was this:
install just using brewso I had control of that installation
added a shell alias that passed MY default config file - something like alias j=”just -f ~/.config/just/justfileto explicitly override any system settings; at one point the startup infrastructure was creating a ~/.jusfilethat imported /usr/share/ublue-os/justfileso overriding that was important. That feature no longer exists now.
Use just (from brew path) for my purposes; ujust for system purposes
I eventually gave up on trying to meld the 2 use cases together - YMMV
FYI - I stopped using just for my own purposes because it ended up being “just” (pun intended) another tool that I really didn’t need. So, I really do not remember other nuances that I ran into. But, the need for the alias and keep user and system uses separate were the main lessons learned.
I am curious why did you wind up doing that? Did using the 60-custom cause problems with updates later on? Using the 60-custom file did work, just wondering if it was the intended use.
I am just installing flatpaks, but I could JUST ( ) as easily use the Ansible scripts I have for my Fedora install, but given that OCI images already are declarative, I wanted to use the tools at my disposal.
I have been playing around with NixOS and if there is one thing I have come to appreciate from all the head bashing to try to learn it, is that having a version-controlled permanent documentation of everything I have done is probably the feature I value most!
That plus some automation gets rid of a lot of issues with things breaking.
In the case of Bazzite, it would have taken me 5 minutes to install the flatpaks manually once but I am trying to learn things, so maybe one day I can make meaningful contributions beyond a very personal flatpak script nobody else is interested in
The choices I made were just part of my journey for adopting atomic desktops. One of the a ha moments I had was when I realized that I should not rely on the stuff installed with the OS for my own use cases - like the stuff in /usr/sbin - in our discussion here, that would be just and ujust.
What I was doing before that was to request additions to the image (like python-tkintermissing from the /usr/sbin/pythoninstallation) which I felt made python incomplete for my needs.
Instead, I garnered a policy of installing via brew, distrobox or locally depending on what it was - even if it was a seemingly dup of what was installed in the bootc image! The list of pre-installed software can change - and HAS - over time.
The bottom line is I feel I should treat the bootc image as a black box - ignoring what is in it. The image is just there to enable how I use my desktop - and the stuff I build / put / use in the various kinds of container tech supported.
Automated installs are a perfect thing to put in a justfile in ~/.config/just. But for those one-off kinds of things I would use a different shell alias that points to a different installs.justfile. But totally agree with the need for that mechanism; and your rationale.
I have also learned to definitely make use of brew - but sparingly. Things I always need (outside of a container) on the host are things I typically install using brew. E.g., bbrew, btop, uv, xclip, zoxide, etc. I do not install a lot - but just is one of those things where I would prefer to install with brew. Automatic (and timely) updates and PATH inclusion are 2 reasons. Note I have observed that updates to new versions come sooner with brew than in my Fedora distrobox container.
I hope that answers your questions. And I appreciate the fact that your are digging deep. I recognize the value in doing just that! (OK I’ll stop now ).
So far I installed things like kvantum which I would otherwise have to install with rpm-ostree, and attempted some DE changes like installing Hyprland.
Flatpaks was me playing with the just scripts
I was learning a couple of things about Podman Desktop too, and how I can run my images inside it and check if what I built works even before I send it to GitHub.
But almost every time I think of something (like I was playing around with the idea of having mesa-git) not long after there is something the Bazzite Devs add that solves that issue in a more elegant way.
I’d love to hear more about how you manage your distroboxes/containers in terms of setup and maintenance. I’m working on a tool that is designed to automate exactly these kinds of things, regardless of what platforms your distroboxes run etc. Feel free to ping me - my email is ashebanow AT cattivi.com
And if you have dots available as well, that would be great too.
The tools I use to manage distrobox / devcontainer images was published to klmcwhirter/oci-shared-images. I document the rationale and usage there. Please feel free to fork it or take what ever you need. It is just a reference implementation of a bunch of ideas. I only maintain it for my own usage. FYI
Awesome. thanks so much. I’ll take a look as soon as I can. But unfortunately for me my aging ass is going in for a colonoscopy in a couple days, and I’m going to be in rough shape doing prep tomorrow and won’t be working. Sorry if that is TMI.
Also, here is the beginning of the PRD I had Claude write for me, slightly edited to make things more up to date with the actual implementation. Its a lot wordier than what I would have written myself, but should give you the rough idea. I’d prefer you not discuss this online yet, but no need for NDAs. All of this is open source anyhow. 100K lines of Go and counting right now including tests. Would love any feedback you might have.
) as easily use the Ansible scripts I have for my Fedora install, but given that OCI images already are declarative, I wanted to use the tools at my disposal.
).