feat(wrapperModules.oh-my-posh): init

[zenoli]

So this is basically a copy of the starship wrapper except:

• "presets" (starship) are named "themes" in omp
• Starship uses TOML, omp uses json by default, which made the build script a bit simpler.

One thing that is missing though:

Omp also allow passing yaml files to --config. I've seen no importYaml equivalent to importJSON/importTOML.
So in order to support YAML we might also allow another option configFile which can be either JSON/TOML/YAML (kinda like I had in my first proposal for the starship module, where @BirdeeHub argued - rightly so - that it was not needed since users can simply use importTOML if they want to write a native toml file.

I was thinking reading from this new option, and normalize the yaml/toml/json to json using yq in the builder and also generalize the order field to define the order between [theme nix-settings configFile].

Thoughts, @BirdeeHub ?

[BirdeeHub]

given the lack of importYAML, having a lib.types.either lib.types.package lib.types.path is fine. It doesn't support an impure path though, because we have to merge it at build time, hence not using wlib.types.stringable

What would the criteria be to determine which type the provided file is of those 3? File extension? Option? Either?

Somewhat busy tonight, will be reviewing stuff again tomorrow night probably

[zenoli]

What would the criteria be to determine which type the provided file is of those 3? File extension? Option? Either?

I was thinking file extension.

config.configFile = ./my-config.yaml;

I try to implement an extra option on top, but only if it is opt-in.

I don't want them to write

config.configFile = {
    path = ./my-config.yaml;
    fileType = "yaml";
}

They should use the single-line syntax from above where fileType will be null and determined by extension.
And they can option in to the longer second syntax if they choose to. I probably can do that by using a spec and path as the main field?

[BirdeeHub]

I try to implement an extra option on top

Dont worry about it, file extension is fine.

[zenoli]

Dont worry about it, file extension is fine.

Done!

[zenoli]

Ok, config merging is fully reworked.

In a nutshell, if you specify multiple settings they will be chained together using the .extends key in the order specified in config.order.

In case you specified an .extends key explictly, we don't modify it (the chain is "broken").

See the description and tests (there are plenty :-)) for more details.

The main use case it, that people might want to use a theme but override some stuff (which was not really possible in my initial version). Since most of the omp settings are in nested lists (segments within blocks) it is a bit clumsy to override them.
I first tried to recreate the mergin logic described in the link above but that was too much work. So making use of the native "extends" feature felt more natural.

[zenoli]

Did some cleanup on the tests. I think this is now ready for review.