Expose lgx-dual as a builder-provided package output

[fryorcraken]

Ask

logos-module-builder currently exposes .#lgx and .#lgx-portable from buildCppPlugin.nix's lgxPackages, but not .#lgx-dual — even though nix-bundle-lgx already ships bundlers.${system}.dual.

https://github.com/logos-co/logos-module-builder/blob/main/lib/buildCppPlugin.nix#L170-L188 (and the equivalent block in mkLogosQmlModule.nix)

lgxPackages = forAllSystems (system:
    let
      bundleLgx         = nix-bundle-lgx.bundlers.${system}.default;
      bundleLgxPortable = nix-bundle-lgx.bundlers.${system}.portable;
      # bundleLgxDual   = nix-bundle-lgx.bundlers.${system}.dual;   ← missing
      …
    in {
      lgx          = bundleLgx         moduleLib;
      lgx-portable = bundleLgxPortable moduleLibForPortable;
      # lgx-dual   = bundleLgxDual     moduleLibForPortable;        ← missing
      …
    }

Why this matters

.#lgx bundles only linux-amd64-dev (works with lgpm, not with Basecamp's portable loader). .#lgx-portable bundles only linux-amd64 (opposite). Consumers who want a single artifact that installs under both paths currently have to pick one or ship two files.

#dual solves this by packaging both variants in one .lgx. It's already the recommended install recipe in stash-basecamp#11, which uses nix bundle --bundler github:logos-co/nix-bundle-lgx#dual as a workaround.

Current workaround

Module authors have to manually wire it in every module flake:

outputs = inputs@{ logos-module-builder, nix-bundle-lgx, ... }:
  let base = logos-module-builder.lib.mkLogosModule { … };
  in base // {
    packages = builtins.mapAttrs (system: pkgs: pkgs // {
      lgx-dual = nix-bundle-lgx.bundlers.${system}.dual pkgs.lib;
    }) base.packages;
  };

This duplicates wiring across every module, and requires each module to pin nix-bundle-lgx (typically via follows = "logos-module-builder/nix-bundle-lgx"). Exposing lgx-dual in lgxPackages would remove the per-module boilerplate.

Proposal

Add lgx-dual (and matching install-dual if relevant) to lgxPackages in both buildCppPlugin.nix and mkLogosQmlModule.nix. It should pass moduleLibForPortable (same input used by lgx-portable) so the portable-linked variant is what's shipped in the dual bundle.

Working example

A working module set using the manual wiring is at fryorcraken/logos-module-tictactoe#5 — happy to convert those flakes back to the idiomatic 3-line form once this lands.

[dlipicar]

One comment about this. It doesn't work with lgpm because you're building the dev version (github:logos-co/logos-package-manager#cli). If you build the portable lgpm (github:logos-co/logos-package-manager#cli-bundle-dir) and portable logoscore-cli (github:logos-co/logos-logoscore-cli#cli-bundle-dir) then you can just use the portable LGX everywhere.

Regardless of this, I guess we can do what you're asking for and add the dual variant lgx as standard output.

[fryorcraken]

@dlipicar I am happy for you to push back on this one. I think the first question is: what is the difference between dev and dev-portable lgx, and most importantly, the expected usage of those?

My current guess (I had no idea when I opened this issue):

• dev -> fast build and iteration, but only works where it was built
• portable -> the proper build to distribute

In this case, dual doesn't really make sense. Right? Or am I missing something.