refactor(default-flatpaks): version 2 (nushell)

[xynydev]

This PR is a draft of the rewrite of default-flatpaks to support multiple repositories, pioneer Nushell-based modules, and rethink the config structure.

Current version implements only the build-time part. Plan is to write to /usr/share/bluebuild/default-flatpaks/configuration.json at build time and read from there in the post-boot parts.

The recipe format is still up for debate. I didn't end up using anything in #146 for now. The current approach is basically the same as my original suggestion, except that one module call can install Flatpaks in multiple scopes from multiple repositories. The terminology still feels off. Feel free to suggest improvements.

Also feel free to look at the source code to see if you mostly understand it and if it is more readable than the v1 source.

The syntax highlighting on GitHub might be a bit weird, though, because I had to make the file end in .sh due to our current system hardcoding that in. I'm not sure what we could do about that, maybe make it possible to omit the file extension entirely.

Testing

recipe:

modules:
  - type: containerfile
    snippets:
      - "COPY --from=ghcr.io/blue-build/nushell-image:0.98.0 /nu/nu /usr/bin/nu"
  - source: ghcr.io/blue-build/modules:nu-flatpaks
    type: default-flatpaks
    installations:
      - notify: true
        scope: user
        repo:
          title: Flathub (user)
        install:
          - io.gitlab.leesonwai.Sums
          - io.github.nokse22.minitext
      - notify: true
        scope: system
        install:
          - xyz.splashmapper.Splash
          - xyz.safeworlds.hiit

example output:

[fiftydinar]

Regarding code structure, it looks cleaner, simpler & I generally like it.

Only thing which clutters things very much is echo-ing in different colours. So message is harder to see in code.
Also, we use colours in bluebuild cli for start & end of the module, so maybe it's better to use message colours only when necessarry for better visualization (f.e. red colour for error message).

Is JSON as a config format necessarry? I find .yml format cleaner. As you said, nu can be used to read/modify YAML files.

Also printing the message for every checked FlatHub flatpak ID is too much imo, it should only print success message once & print error when ID is wrong.

Recipe format looks good to me, except maybe instead of installations, modifications can be used.

Thanks for starting this PR, I'll look into learning Nushell, so I can also contribute

[xynydev]

Regarding code structure, it looks cleaner, simpler & I generally like it.
...
Thanks for starting this PR, I'll look into learning Nushell, so I can also contribute

Nice!

Only thing which clutters things very much is echo-ing in different colours. So message is harder to see in code.
...
Also printing the message for every checked FlatHub flatpak ID is too much imo, it should only print success message once & print error when ID is wrong.

Ok, maybe I went a bit overboard with that. I'll fix that in the next commits.

Sure

Also, we use colours in bluebuild cli for start & end of the module, so maybe it's better to use message colours only when necessarry for better visualization (f.e. red colour for error message).

Do we? I haven't seen that.

Is JSON as a config format necessarry? I find .yml format cleaner. As you said, nu can be used to read/modify YAML files.

It's not a config format for humans, it won't be writeable as it will exist only in the /usr/share/ directory. I thought that JSON would be better as a serialization format for data written and read by computers only. We can change that though if you wish, it's not a big deal.

Recipe format looks good to me, except maybe instead of installations, modifications can be used.

Those "modifications" can't actually modify each other, though... I chose "installations", because it IMO reflects that each entry means one set of Flatpaks installed from a specific repo to a specific scope. I guess it feels redundant with the install: key though. We might consider renaming that to applications: or something.

[fiftydinar]

Also, we use colours in bluebuild cli for start & end of the module, so maybe it's better to use message colours only when necessarry for better visualization (f.e. red colour for error message).

Do we? I haven't seen that.

We can change that though if you wish, it's not a big deal.

It's easier to read for users who want to know what's modified in the image, hence the reason I insist on it.
But it's not a big deal.

Those "modifications" can't actually modify each other, though... I chose "installations", because it IMO reflects that each entry means one set of Flatpaks installed from a specific repo to a specific scope. I guess it feels redundant with the install: key though. We might consider renaming that to applications: or something.

default-configuration:?

[xynydev]

default-configuration:?

I don't really like that either, because it's two-parted and does not feel like it makes sense for a list of separate configurations. Maybe configurations: would make sense?

[fiftydinar]

Maybe configurations: would make sense?

Looks good to me