template: require Mac + Linux build support - #67
Conversation
Add a Supportability criterion to the prize template requiring submissions to build and run end-to-end on both macOS (Apple Silicon) and Linux (x86_64). The current template is silent on platforms, leading to darwin-only flakes that block Linux reviewers at nix evaluation time. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
✅ Validation passedA reviewer will assess against the prize criteria. Automated check. See solution template and TERMS. |
1881de8 to
aae09b1
Compare
- Trim the cross-platform bullet: state the outcome (works on both platforms) rather than prescribing the implementation. The earlier wording told builders how to structure their flake, which isn't the template's job. - Add a new Supportability bullet pointing builders at logos-module-builder + the Logos tutorial. Hand-rolled module flakes are how cross-platform packaging breaks in the first place; the shared builder already handles Mach-O vs ELF correctly. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
aae09b1 to
43819bf
Compare
|
either that, or we could do some pricing per platform 80% if it works on one platform, 100% if it works on both. Not sure what most convenient as we can't expect everyone to have access to both. |
|
what about requiring pre-built |
|
Happy to amend my PRs btw to support both via |
|
@fryorcraken let's merge this criteria as I want to be able to check submissions on my VPS. |
I would not say "prebuilt", too risky. I'd prefer a reproducible build of Ideally, it is part of the CI of the submission: the CI builds a |
|
Note that as part of #93, we would probably want an automated way to build the artefact for both platforms so it's verifiable. |
…-action Basecamp modules must be published to a catalog forked from logos-modules-release-base, using logos-modules-release-action to build, verify, and release the .lgx — completing the pipeline started by the logos-module-builder requirement. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
- Testimonial mini app: reference SDK integration that inscribes "I use this wallet" on both the blockchain and the official Logos zone. Doubles as the canonical example for third-party devs and the tool that produces the adoption criteria's on-chain inscriptions. - Name the official zone by sequencer endpoint rather than a number: zones are identified by ChannelId/endpoint, not sequentially, so there is no zone number to cite. Testnet 0.3 endpoint TBC at open. - Discretionary UX-quality criterion, per the forward plan's "volume + usability/UX signal" dimension. - No mandatory external services: any third-party service (e.g. price API) must be disclosed, disableable, and non-essential. - Adopt the Supportability requirements from PR #67 (cross-platform build, mkLogosModule, module catalog publishing), since that template change is not yet merged and so is not inherited.
4 participants
Summary
Add two Supportability criteria to the prize template (
prizes/LP-0000.md):logos-module-builderfor Basecamp modules — Basecamp module flakes must usemkLogosModulefromlogos-co/logos-module-builder(per the Logos tutorial) rather than hand-rolling derivations. Cross-platform packaging (Mach-O install names, ELF RPATH, etc.) lives in the shared builder so individual modules don't have to re-solve it — and don't get to solve it wrong.Motivation
Reviewing LP-0017 (#58) on a Linux x86_64 host surfaced both gaps:
nix build .#lgxat evaluation time because it unconditionally referencespkgs.darwin.cctools(a macOS-only package) in a hand-rolledpostFixup.logos-module-builder. Had it used the standard builder, the platform fixup would have been handled centrally and the Linux build would have just worked.The template was silent on both points, so neither the builder nor the reviewer had a shared expectation.
Scope
prizes/LP-0000.mdso new prizes inherit the requirements.Test plan
prizes/LP-0000.mdrenders cleanly on GitHub.prizes/LP-0000.mdis modified.🤖 Generated with Claude Code