Tracking issue regarding changes required to support new modules

[xynydev]

We have discussed the usage of Nushell for developing modules here: blue-build/modules#212
We're working on a v2 of the default-flatpaks module here: blue-build/modules#336

Here's a quick list of things that need to be implemented in CLI to finish off the support for the new types of modules and default-flatpaks v2:

• Support for modules published as separate images under the source image path
  • See https://github.com/blue-build/modules/pkgs/container/modules%2Fdefault-flatpaks
• Support for specifying the version of the module to use (corresponding to the image tag)
  • Proposed syntax: type: default-flatpaks@v1, type: default-flatpaks@v2, type: default-flatpaks@latest etc.
  • Fetch @latest by default
  • Needs schema changes
• Support for module scripts without .sh suffix
  • A script in Nushell should not use the .sh suffix.
  • Need to figure out how to handle existing modules, including custom modules
  • Ideas:
    1. Expect .sh to be there by default, unless the module.yml declares that the module is in Nushell
    2. Expect .sh to not be there, rename the script files of all modules (would break builds with earlier versions, but could be mitigated with symlinks) (local modules might need a different procedure)
    3. Run the Nushell module with a bash wrapper (using an .sh file that is a shim for the .nu script) (no CLI changes required)
• Support for modules written in Nushell
  • https://github.com/blue-build/nushell-image shall be used as the distribution mechanism for Nushell
    • Ex. COPY --from=ghcr.io/blue-build/nushell-image:0.98.0 /nu/nu /usr/bin/nu
  • Ideally the supported Nu version is declared by the repository (or possibly even the module)
  • But it would be wasteful to ship multiple Nu binaries in the images
  • It would be wasteful to ship a Nu binary at all if the module does not have any post-boot elements
  • Ideas:
    1. Modules using Nushell declare the version the want in their module.yml, that is read by the CLI, and that image is bind-mounted to their RUN-step. If a module needs Nushell post-boot, it can cp the binary to the appropriate location.
    2. Modules using Nushell declare the version the want in their module.yml, that is read in the build process for the module repository, and the binaries are added into the image for the module alongside the source code. If a module needs Nushell post-boot, it can cp the binary to the appropriate location.
    3. Nushell replaces yq (and possibly others) and goes alongside bluebuild as one of the binaries that gets included in every image. The version is the same across all builds and modules (need to make sure all modules support the newer version before upgrading, but wasting resources on shipping multiple versions becomes impossible).