blue-build / modules

BlueBuild standard modules used for building your Atomic Images
Apache License 2.0
22 stars 26 forks source link

feat: Add Chezmoi module #215

Closed exponentactivity closed 1 month ago

exponentactivity commented 2 months ago

I'm implementing a chezmoi module, inspired by #155 and this forum post, and i need help from the community.

Everything should work but my initial tests failed due to needing curl while building the image to download the chezmoi binary, and that is not available in the image used to build the modules. So i thought this would be a good time to reach out to figure out the best way forward, instead of figuring out a solution that Works For Me™.

How would you prefer the module install chezmoi? Better solutions for installing chezmoi, pointers to improve the documentation or any other feedback is very welcome.

gmpinder commented 2 months ago

If you're having issues with curl, you could try wget. I believe wget is a standard binary in Fedora.

exponentactivity commented 2 months ago

If you're having issues with curl, you could try wget. I believe wget is a standard binary in Fedora.

Curl turned out to be included in the build image, the issue was syntax errors caused by me being bad at bash.

Right now, the script seems to work as intended (when i set the default variables manually), except for the variable defaults not being set, despite having double checked the syntax, and tried it in a shell. All variables with defaults end up with a value of null.

I seem to be missing something. If someone could take a look and see what i'm missing i would be very grateful!

fiftydinar commented 2 months ago

Thanks for the PR.

About this module scope, I think that we are more striving for some universal homefiles module, rather than some discrete chezmoi module.

Issue about the proposed homefiles module idea: https://github.com/blue-build/modules/issues/118

In other words, we maybe can use chezmoi as a backend for homefiles module if it can be integrated in that way, but by looking at the project, it seems that the separate repo is needed just for dotfiles, which is not ideal. Ideally, it would just look for homefiles in /config/homefiles in the image repo or something similar.

This is something that needs to be evaluated further, but module itself generally looks good.

the variable defaults are not being set, despite having double checked the syntax, and tried it in a shell. All variables with defaults end up with a value of null.

I'm not sure why that happens, I will try to look something out.

Alternatively, you may try to use if/else statement. If string has 0 characters (null), assign the default variable, else assign the variable that is inputted from the module recipe file.

exponentactivity commented 2 months ago

I'm not sure why that happens, I will try to look something out.

Alternatively, you may try to use if/else statement. If string has 0 characters (null), assign the default variable, else assign the variable that is inputted from the module recipe file.

I fixed it with if statements. The problems seems to have been VAR=$(echo "$1" | yq -I=0 ".var") outputting the string "null" as opposed to the value null. Thus making the var:-default value "correctly" think the value was already set.


About this module scope, I think that we are more striving for some universal homefiles module, rather than some discrete chezmoi module.

Issue about the proposed homefiles module idea: #118

In other words, we maybe can use chezmoi as a backend for homefiles module if it can be integrated in that way, but by looking at the project, it seems that the separate repo is needed just for dotfiles, which is not ideal. Ideally, it would just look for homefiles in /config/homefiles in the image repo or something similar.

This is something that needs to be evaluated further, but module itself generally looks good.

Keeping the dotfiles inside the build repo, could at the very least be done as a git submodule. I don't know if chezmoi supports installing from a subdirectory of a repo, but i can look into that. I don't really see how that would be a better alternative as that would only be available at build time, and it would complicate using them on different platforms. But please enlighten me!

What would be different about a generic homefiles module, as opposed to this? Would dotfiles be installed at build time? If so, how would they be updated?

Having a choice between chezmoi and other dotfile managers would be cool, though!

fiftydinar commented 2 months ago

What would be different about a generic homefiles module, as opposed to this? Would dotfiles be installed at build time? If so, how would they be updated?

I think there is misunderstanding here.

homefiles module is just a proposal, not something that is currently implemented. Hence why I mentioned that chezmoi could be used as a backend for it.

If you look at the linked issue, you can notice that it's talked about on how to update those files & that using something like /usr/etc/skel is not suitable. Chezmoi is also suggested, which currently seems to be the best available alternative.

I think it is more intuitive to have homefiles as the name of the module, than chezmoi. Most users would immediately know what homefiles module is, while chezmoi takes some searching to know what it is, as it's a technical package word.

That's the reason why I mentioned it, as BlueBuild focuses on having good docs + presenting intuitive & easy-to-understand information.

exponentactivity commented 2 months ago

Oh, yes i definetly misunderstood. I see how renaming it would make sense. Was that what you meant?

fiftydinar commented 2 months ago

Oh, yes i definetly misunderstood. I see how renaming it would make sense. Was that what you meant?

Yes

xynydev commented 2 months ago

A homefiles module couldn't IMO use chezmoi as a backend, because that's overkill for simple usecases, and I wouldn't want to bother with chezmoi since the UX isn't right for me and I have just a single machine. I haven't looked at the code here yet, but if it's clean, I wouldn't be opposed to merging it.

fiftydinar commented 2 months ago

A homefiles module couldn't IMO use chezmoi as a backend, because that's overkill for simple usecases, and I wouldn't want to bother with chezmoi since the UX isn't right for me and I have just a single machine. I haven't looked at the code here yet, but if it's clean, I wouldn't be opposed to merging it.

In that case, I think that the only thing that remains is to fix modification to cosign.pub, as that shouldn't be touched in this repo, like gmpinder noticed in review thread.

Maybe some README touchups if it doesn't render correctly on the website.

And, I'm not sure if option of user session lingering should be offered to start chezmoi during boot process, as I'm not sure if that option is beneficial at all if the service can get started after boot. I'm not sure how much that option is reliable, if it has some security implications or some other related things.

exponentactivity commented 2 months ago

And, I'm not sure if option of user session lingering should be offered to start chezmoi during boot process, as I'm not sure if that option is beneficial at all if the service can get started after boot. I'm not sure how much that option is reliable, if it has some security implications or some other related things.

It seems like user session lingering needs to be enabled per user complicating the solution quite a bit. I'm not sure it would be beneficial, at least for the way i use dot files, as i only use them for stuff i want in my interactive sessions. If someone has a use case for it, i'm open to implementing it.

Maybe even a module with a broader scope of similar "system settings" if more uses were found? Sorry, for going off topic.