Skip to content

Latest commit

 

History

History
83 lines (65 loc) · 4.4 KB

File metadata and controls

83 lines (65 loc) · 4.4 KB

Packaging Aviary as a macOS .dmg

cargo install tauri-cli --locked          # once; version 2
cargo tauri build --bundles app dmg       # from the repository root

The artefacts land in target/release/bundle/: macos/Aviary.app and dmg/Aviary_0.1.0_aarch64.dmg, around 17 MB and 5.5 MB.

No icon step is needed. icons/ holds PNGs only, and the bundler generates Aviary.icns from them — a 512×512 source, so the largest Finder size is scaled rather than drawn. cargo tauri icon would want a 1024×1024 original, which this project does not have.

The part that is not the command

Four kinds of data are runtime TOML and JSON, not compiled in — that is a design decision, and the reason "support one more agent" is one more file rather than a rebuild:

what shipped from found beside the executable as
46 agent profiles crates/aviary-profile/profiles/ profiles/
33 history providers crates/aviary-history/providers/ history-providers/
2 locales crates/aviary-tauri/locales/ locales/
the price list crates/aviary-history/prices.toml prices.toml

bundle.resources in tauri.conf.json puts all four into the bundle. On macOS they land in Aviary.app/Contents/Resources/, while the executable is in Aviary.app/Contents/MacOS/ — so every one of those lookups also probes ../Resources/. That line is what makes a packaged build read its own files; see the note on it in ProfilePaths::find_builtin.

Why this is worth stating rather than assuming

Before those lines existed, the lookups fell through to env!("CARGO_MANIFEST_DIR") — an absolute path on whatever machine ran the compiler. Measured, with a bundle whose Resources/profiles held two profiles:

resources in Contents/Resources  →  21 agents installed    (the build machine's repository)
resources in Contents/MacOS      →   2 agents installed    (the bundle's own copies)

So the app worked for whoever built it and, for everybody else, said this:

$ AVIARY_PROFILES_DIR=/tmp/empty aviary inventory
0 agents installed, 0 entities total

Not an error. A confident false statement about the reader's machine, which is the worst thing this program can say — and one that no amount of testing the build locally would ever show.

The check that proves it is fixed is to hide the repository's copies and run the bundle alone:

mv crates/aviary-profile/profiles /tmp/away/          # and providers, locales, prices.toml
cd target/release/bundle/macos/Aviary.app/Contents/MacOS && ./aviary inventory

With all four hidden, the bundled binary still reports every installed agent and every entity, still resolves a history provider only the bundle now has, and still renders rule text as English sentences rather than as audit.a11.title. The price list is the one of the four with no CLI command behind it, so it is confirmed present in the bundle and exercised only through the app's money panel — where being unreadable shows as — and never as 0.

What this dmg is not

  • Not signed, not notarized. codesign -dv reports adhoc, linker-signed. Gatekeeper will refuse it on any Mac other than the one that built it: the first open needs right-click → Open, or xattr -d com.apple.quarantine /Applications/Aviary.app. Distributing it without that caveat wastes the reader's first two minutes on a dialog that says the app may be malware. A Developer ID and --target aarch64-apple-darwin --bundles dmg with notarization is the fix, and it costs an Apple developer account.
  • Not universal. aarch64 only, because that is what built it. --target x86_64-apple-darwin builds the Intel half; a universal binary needs both targets and lipo.
  • Still carrying the build machine's path. The bundled binary contains four occurrences of the absolute path to the repository it was compiled in, from the CARGO_MANIFEST_DIR fallback that is now never reached at runtime. Dead weight, and a leak of the builder's home directory in a public artefact — the same class of thing nothing_identifying_is_published exists to stop, which walks tracked files and not compiled ones. Removing it is not a one-liner: cfg(debug_assertions) would strip it from release builds and break cargo test --release, which relies on it. The honest fix is for tests to take an explicit directory, which is what expand_path already argues for from the other side.