[mksybr]

i just glob over *.default and *.default-release `mkdir -p chrome` and move it there then check if my user.js has the setting that enables legacy userchrome (via grep, (useless) cat, and pipe), and if not add it. wouldnt guix do something similar if it managed my userChrome.css?

i am not sold on the maintainability delta between my script and a guix one, but i only use a text editor, a terminal emulator and two web browsers for 90% of my use, so maybe im just too small scale to run into the maintainability issue it's trying to solve. the main struggle i have is in making the config files, and guix would only add another layer to that.

easy to learn might be a valid consideration for me if i didn't already feel comfortable with scripts of the normal non guix variety, but the devil i know does fine.

[dbeley]

NixOS is overriding the profile name by using your username so the name is not auto-generated anymore (NixOS hates that) so it knows the user profile will always be at ~/.mozilla/firefox/USERNAME. It automatically creates a ~ /.mozilla/firefox/profiles.ini with a custom profile.

[mksybr]

That's a nice small benefit that seems dwarfed by the increase of complexity, but maybe I am blind to my death of a million paper cuts that I've grown used to.

Maybe I'll update my script to use named instead of randomly generated profiles, though.

What does it do for multiple profiles?

[dbeley]

You can specify as many profiles as you want, you have a property called firefox.profiles that can be an array and you would declare as many settings you would want in it. They still need to be names though (either through a variable like an username or a name you would set yourself).

[kaba0]

It’s increasine in complexity when you are writing shell scripts, it is not when you have a proper system in place that provides a sane abstraction/interface for defining such configurations.

[mksybr]

Guix is a huge upfront increase of complexity for someone who already has a shell script to do the same thing.