[FEATURE] OS specific profiles

[dnaka91]

Is your feature request related to a problem? Please describe.

I'm using toml-bombadil on both Linux and macOS and currently solve differences by having a separate macos profile with different variables and different dot locations.

With #141, I could omit several of those settings (mostly differences in font sizes). But that doesn't cope for different settings locations. For example, for Visual Studio Code the user settings are located in ~/.config/Code/User/settings.json on Linux, but in ~/Library/Application Support/Code/User/settings.json.

It would be great to have some way to define different targets for different OSs.

Describe the solution you'd like

Eventually having some pre-defined profiles that are auto-enabled depending on the OS? That would mean we perhaps have profile.windows, profile.macos and Linux being the default profile. Then, depending on whether Windows or macOS are detected, they'd be automatically be added to the enabled profiles.

That would potentially break some templates, as people might already have profiles with the same name. Could get around that by making a special category like profile.os.*, to make clear these aren't user-defined profiles, but pre-defined.

Describe alternatives you've considered

Nothing else really. My current solution with the macos profile works well, but easy to forget to enable the profile.

Additional context

A basic idea how the settings could be defined:

dotfiles_dir = "Projects/dotfiles"

[settings]
vars = ["vars/colors.toml", "vars/font.toml"]

[settings.dots]
vscode = { source = "editor/vscode.json", target = ".config/Code/User/settings.json" }

# Auto-enabled profile when on macOS
[profiles.os.macos]
vars = ["profiles/macos/vars/font.toml"]

[profiles.os.macos.dots]
vscode = { target = "Library/Application Support/Code/User/settings.json" }

# Auto-enabled profile when on Windows
[profiles.os.windows]
# Something Windows-specific here

[oknozor]

Actually I am working on a complete rework off the template system on #213.
The main idea is that now variable are not only key values pair but can be any toml structure.
Default variables are loaded by default such has a list of available profiles so we can write things like this in dotfile templates:

{% if "onagre" in profiles %}
set $launcher "WGPU_BACKEND=vulkan onagre"
{% elif "wofi" in profiles %}
set $launcher "wofi --show drun"
{% endif %}

I would advice against implementing default os profiles before this is merged since this is a breaking change.
Also my own idea was to add a os variable in the variable context using std::env::consts::OS instead of using profiles.

This would be way easier to implement and would allow to write os specifics is the same template like so :

{% if os = "linux" %}
font-size: 20px;
{% elif os = "macos" %}
font-size: 30px;
{% endif %}

Would this solution work for you or would you still need need os profiles ?

The PR is almost done, I am actually using it in my current setup. But it involves rewriting the doc entirely.
I need to find some time to finish it before making a release. I you want to test it you can install from source and take a look at
my dotfiles to see how the new variable system works.

[dnaka91]

That sounds really nice. Was hoping that at some point the template context would be extended to allow for whole structs.

This solves half my problem. What still remains is, that I sometimes need a different template target location, based on the OS 🤔.

---

A small suggestion for the above os variable. Another way of defining it in the context, would be a struct of bools, where the field names are the possible OS variants. That would avoid any string misspelling, as the template engine would error on any unknown field in os. It would error out early, instead of silently picking another if branch because of a wrong spelling.

{% if os.linux %}
font-size: 20px;
{% else if os.macos %}
font-size: 30px;
{% endif %}

[i2]

Hi, Is this available for Windows too? Thanks!

[ I decided to ask here instead of opening a new issue.]

[oknozor]

I am not sure why you'd want to use toml-bombadil on Windows.
There are a bunch of Unix specific stuff in toml-bombadil that would make it hard to use on Windows.
That said I am no expert, maybe you can get it work with wsl2 ?
Nevertheless the os global variable would work on any Rust os target, so it would work on windows.

Note that this is not implemented yet.

[i2]

I see. I was essentially looking for chezmoi implemented in rust, and rust being a cross-platform one binary deliverable, I thought I'd ask. Thanks for clarification.

[flying-sheep]

I’m currently hacking around this by overriding the bombadil link command to always supply the appropriate profile:

def 'bombadil link' [] {
  ^bombadil link -p $nu.os-info.name
}

(nushell both has the OS name readily available and allows defining functions overriding subcommands only)

but this feature would be a great addition.

---

An alternative for @dnaka91 and my specific problem would be to provide special variables exposing OS-specific directories: #258

[dnaka91]

This feature loses more and more importance for me, actually. I almost exclusively use my Linux system now, and the current workaround is pretty easy.

I was thinking to start an implementation for this feature, but I'd probably start on #230 first before I get started on this issue here.

[oknozor]

this is now implemented (see: https://oknozor.github.io/toml-bombadil/guide/templates.html#default-variables)

[flying-sheep]

very cool! thanks!

[flying-sheep]

Wait, how do I derive target from a variable?

[oknozor]

This is not possible yet, we probably need another issue for this.

[flying-sheep]

I mean, this issue is called “OS specific profiles”, which isn’t actually implemented.

You need to know if interpolating variables in the bombadil.toml is actually possible (since according to the docs, the config file defines which files to pull variables from, and both using and defining variables in the same file seems like a bit circular/complicated)