Distribute lux through Homebrew and WinGet under the Anderix identity

[anderix]

Distribution, not a language feature — this does not touch the freeze. The one judgement call is noted under the lux update item below.

Decision (2026-08-09): lux is permanently an Anderix project. That settles the identity question left open on 2026-07-31, when apt, brew, and WinGet were treated as one all-or-nothing package because no standalone anderix distribution identity existed yet. It does now, so the three legs can be judged on cost instead of branding. Homebrew and WinGet are in. apt stays deferred — not on identity grounds any more, but because it is the only one of the three that needs infrastructure you have to stand up and host, and the 2–3 personal CLI threshold for that still hasn't been met. Nothing here goes under Excelano; a personal teaching project carrying business branding is the regret path and the arrow only points anderix → excelano.

The motivation is trust at the front door, not reach. irm https://anderix.com/lux/install.ps1 | iex is the exact shape of the instruction a careful parent should refuse, and the Track B cold test puts lux in front of a stranger's parent who has no reason to extend the benefit of the doubt. winget install lux and brew install lux don't ask anyone to override a good habit. That framing also fixes the timing: these want to be live comfortably before the cold test runs, not after it, and certainly not held back for 1.0 — Track B is the gate on 1.0, so waiting for 1.0 gets the order exactly backwards.

1. lux update has to learn where lux came from — and this lands first

This is the blocking prerequisite, not a follow-on. update_cmd in src/main.rs:473 has no idea how lux was installed. On Unix it unconditionally runs the cargo-dist installer through the vanity URL, which writes into ~/.cargo/bin. A learner who installed with brew ends up with two binaries — the Homebrew one and the cargo-dist one — and PATH order decides which answers lux. The failure mode is silent: the command prints "Done. Run lux --version to see what you're on," and lux --version reports the old version. A later brew upgrade then overwrites only the copy brew knows about.

Windows is worse, and worse in a way that attacks the whole reason for doing this. The Windows branch prints irm … | iex, so the parent who deliberately chose WinGet to avoid piping a URL into a shell is told by lux itself to pipe a URL into a shell. If they follow it, they get a second copy outside WinGet's bookkeeping and a later winget upgrade quietly reverts them.

The fix costs no dependency: std::env::current_exe() is std. If the running binary sits under a Homebrew prefix (/opt/homebrew, /usr/local/Cellar, /home/linuxbrew/.linuxbrew) print brew upgrade lux and stop; if it sits under WinGet's packages directory print winget upgrade Anderix.lux and stop; otherwise behave exactly as it does today. Keep the command rather than removing it on those channels — the learner shouldn't have to remember how lux arrived on their machine, and handing back the right next step is the same trail-not-pointer stance the diagnostics take. Watch the symlink detail: Homebrew links into bin/ while the real file lives in the Cellar, and current_exe() canonicalizes on both Linux and macOS, so match on the resolved path and test it rather than assuming. Verify WinGet's actual install path when the manifest is built instead of hard-coding a guess.

Ordering matters more than the code here. The README, lux --help, and the post-update nudge all point people at lux update, so the moment a tap or a manifest exists, every user who follows lux's own advice lands in the shadowed state. This must be released before the first tap or manifest, not alongside them.

The freeze call: I read this as outside the freeze — it's install plumbing, it changes nothing a learner writes, and it isn't an enhancement so much as a precondition, since the defect only comes into existence once brew and WinGet do. It is the closest call so far, though. If the record should be unarguable, the clean alternative is to write it after 2026-09-05 and ship both channels behind it, which costs a few weeks and no ambiguity. David's call.

2. Before either manifest: check the name

Pushing into public indexes is a distribution act under a name, and lux is a common word with commercial users in several categories. Do a trademark search before submitting anything, not after. Separately, check what winget install lux actually resolves to: the package identifier is namespaced and safe as Anderix.lux, but the moniker is not namespaced, and the moniker is the short command that goes in the README and carries the whole trust argument. crates.io is the precedent that the plain name isn't always free — the crate had to become luxc because lux was a real, unclaimable 2016 package.

3. Homebrew — cheap and automated, do it first

cargo-dist already ends every release with publish-homebrew-formula. This needs an anderix/homebrew-tap repo, the tap declared in dist-workspace.toml, and a token, and then formulas update themselves on every tag. It must be a new anderix tap, not excelano/homebrew-tap — both for branding and because lux being alone in its own tap sidesteps the multi-repo tag race documented in ~/notes/build_release_gotchas.md, where four Rust repos tagged within a minute of each other collide committing to the shared tap.

Do this leg first. It is roughly an afternoon, it is fully automated afterwards, and it proves the Anderix publisher identity end to end on the channel where nothing can go slowly wrong.

4. WinGet — start early, because the latency isn't yours

This is the opposite of the brew leg on every axis. Nothing in the fleet automates it: neither xray nor xshape has a komac workflow, so every release is a hands-on submission. On top of that sits the Defender queue, where an unsigned Rust binary can stall for days and there is no code signing cert (declined 2026-07-30, and not to be re-pitched). The recipes and the hard-won gotchas are all in ~/notes/build_release_gotchas.md — read the whole WinGet section before starting, particularly the workflow token scope trap, the CRLF-in-manifests trap, and the rule that @wingetbot run is moderator-only. Expect a first submission under a brand-new Anderix publisher namespace to draw more scrutiny than a routine update to an established one, and start it early for that reason alone.

One decision to make deliberately rather than by default: a WinGet manifest that rots behind the curl installer is worse for trust than no manifest at all, because the parent who took the legible path ends up on an older lux than the one who didn't. Either wire an auto-update workflow — which the whole fleet would benefit from, since none of the eight packages has one — or decide that WinGet tracks meaningful versions rather than every patch, and say so plainly in the README.

5. Docs

The README's Installing section gains brew and WinGet alongside the existing one-liners, and the site install page follows (that belongs to the anderix.com session, not this one). Keep the vanity URLs as they are — they stay the canonical path for people who want them, and lux update keeps using them for cargo-dist installs.

Note also that issue #84 describes lux as already distributed "through crates.io, apt, Homebrew, and the vanity install URLs," which isn't true today and won't be true afterwards either, since apt is staying deferred. Worth correcting there when that issue is picked up.

Suggested order

1. lux update provenance detection, released.
2. Name and moniker check.
3. anderix/homebrew-tap and the cargo-dist wiring.
4. WinGet submission, plus the decision on manifest cadence.
5. README.

Raised from the lux vision session; the reasoning behind the identity decision is in ~/notes/lux_vision.md. The all-or-nothing paragraph in ~/notes/lux.md is now superseded and should be updated by whoever owns that dossier.

[anderix]

Item 1 is shipped, and the name check is done. Both changed what the rest of this issue should say, so recording it here rather than in a commit message.

Item 1 — lux update provenance detection, shipped in 0.19.11 (8f5feae), names corrected in 0.19.12 (22a849c). current_exe() classifies the running binary before anything else happens: a Homebrew prefix is handed brew upgrade anderix/tap/luxc, a WinGet path is handed winget upgrade Anderix.luxc, and everything else behaves exactly as before. The command stays on those channels rather than being removed. Matching is on the resolved path, since Homebrew links bin/lux into its prefix while the file lives under Cellar and current_exe() follows symlinks on Linux and macOS. /usr/local counts only under Cellar, so a hand-built lux copied to /usr/local/bin is not sent to a package manager that never had it. Both package managers are matched on every platform rather than behind cfg, so the Windows branch is covered by the suite on a Linux runner. A miss falls through to the installer, which is what lux did on every channel before this, so an unrecognised prefix costs what it already cost.

Item 2 — the name is not free on either channel, and the answer is luxc. On Homebrew, lux in homebrew-core is iawia002/lux, a video downloader, formerly annie. Core wins the short name over any tap permanently, so brew install lux would keep installing unrelated software no matter what a tap contains — it succeeds, which is worse than failing. On WinGet, Moniker: lux belongs to JackDevey.Lux, a Govee light-strip CLI, and igoogolx.lux holds the plain package name, so winget install lux is ambiguous and errors out. luxc is free on both, verified rather than assumed: homebrew-core 404s on it, and winget search, --moniker and show all come back empty. So the package is luxc on both channels, matching what crates.io already forced, and the binary stays lux. One rule across three registries. The manifest should not claim Moniker: lux — it is optional, it is already held, and a third claimant would deepen an ambiguity that is currently other people's problem.

Trademark was screened, not cleared. No standalone LUX word mark surfaced in the software classes; what is live there is compounds (F.LUX, LUX ALGO, LUX FTS, LUXRIOT). Justia blocked direct fetching and the USPTO register was not queried, so this rules out the obvious blocker and nothing more.

Two corrections to this issue. Item 3 says cargo-dist already ends every release with publish-homebrew-formula. Not in this repo — dist-workspace.toml declares installers = ["shell", "powershell"] with no homebrew installer and no tap key, so that job has never run for lux. It is true elsewhere in the fleet, which is where the memory comes from. The brew leg therefore needs the dist config edited and regenerated, not just a tap repo and a token.

And the framing paragraph says winget install lux and brew install lux do not ask anyone to override a good habit. Both of those commands are taken, so the qualified forms are what the README will show: brew install anderix/tap/luxc and winget install luxc. The trust argument survives unchanged — neither asks anyone to pipe a URL into a shell — but the short-command version of it was wrong.

Remaining, in order. The tap repo and the dist wiring; the WinGet submission and the decision on manifest cadence; the README. Note that luxc being free in homebrew-core today does not reserve it, so anderix/tap/luxc is the form to document and the unqualified one is a convenience that could break.

[anderix]

Item 3 is done and verified end to end.

The tap is live. anderix/homebrew-tap, public. dist-workspace.toml gained homebrew to installers, tap = "anderix/homebrew-tap", and publish-jobs = ["homebrew"] — that last one matters, because without it the formula is built and attached to the GitHub release but never reaches the tap, which looks like success. release.yml was regenerated with dist 0.31.0, matching cargo-dist-version. The generated job checks out the tap with secrets.HOMEBREW_TAP_TOKEN, confirming the secret name against the workflow rather than the docs. dist also warned that the crate had no homepage, so the formula would have shipped without a link to the project page; Cargo.toml now declares one, which fills the same gap on the crates.io listing.

0.19.13 (65ff7f9) is the first release to publish a formula. Every job passed, and Formula/luxc.rb landed in the tap. The formula installs the lux binary on all four Unix targets; Windows is absent, which is correct — that is WinGet's leg.

lux update was tested against a real Homebrew install and printed brew upgrade anderix/tap/luxc. That is the part fixtures could not prove: current_exe() had to resolve bin/lux through Homebrew's symlink to the Cellar path and match the prefix there. It does. Item 1 now has a witness rather than a unit test.

Decided: lux update keeps printing the command rather than running it. brew upgrade cannot be run narrowly — by default it triggers Homebrew's auto-update, which refreshes every tap and touches state unrelated to lux, and suppressing that with HOMEBREW_NO_AUTO_UPDATE=1 produces the worse failure, where stale tap metadata makes the upgrade report you are already current when a newer lux exists. That choice belongs to whoever installed Homebrew. Windows forces print-only regardless, since a running lux.exe cannot be replaced and winget upgrade hits the same lock, so running brew while printing winget would trade a coherent rule for an incoherent one. And the person who chose a package manager chose it to be in charge, which is the trust argument this whole issue rests on. The residual cost is real and worth naming: lux update means one thing on the installer channel and another on the package channels. The resolution is to be clear about the contract — it gets you to the latest lux, and where it cannot safely take the last step it tells you exactly what will — not to force symmetry.

On the short form. Nothing in homebrew-core is called luxc, so brew install luxc resolves to this tap once it is installed, and fails before that since Homebrew does not search taps it has never heard of. It is borrowed rather than owned: if a luxc ever lands in core, core wins and the short command silently changes meaning — the same failure that made lux unusable, deferred. The README should print brew install anderix/tap/luxc and not mention the short form.

Remaining. The WinGet submission and the decision on manifest cadence, then the README's Installing section.