feat(bundle): use tauri-native resources + dynamic bundle path detection

[TimeToBuildBob]

Summary

Replace the hardcoded /Applications/ActivityWatch.app/Contents/... discovery paths with runtime detection via current_exe(), so module discovery works regardless of install location.

Changes

dirs.rs — dynamic resource path detection

Replace the hardcoded /Applications/ActivityWatch.app/Contents/... discovery paths with runtime detection via current_exe():

// Contents/MacOS/aw-tauri  →  go up two levels  →  Contents/Resources
if let Ok(exe_path) = std::env::current_exe() {
    if let Some(contents_dir) = exe_path.parent().and_then(|p| p.parent()) {
        let resources_dir = contents_dir.join("Resources");
        if resources_dir.exists() {
            discovery_paths.push(resources_dir.join("modules")); // tauri-native layout
            discovery_paths.push(resources_dir);                  // legacy compat
        }
    }
}

Why this matters: The old code only worked when installed at /Applications/ActivityWatch.app. Users who move the app to ~/Applications/ or run from a downloaded DMG had no module discovery.

tauri.conf.json — (reverted)

The companion bundle.resources config entries were removed in 1dbc66b to keep aw-tauri CI self-contained. The activitywatch build system injects resources at build time via --config.

What was verified

• Greptile P1 (Contents/MacOS path drop): Confirmed false positive — build_app_tauri.sh puts all modules in Contents/Resources/<name>/; Contents/MacOS/ only contains the aw-tauri binary
• Greptile P2 (unnecessary .clone()): Fixed in faa6c6e

Greptile Findings Status

Finding	Status	Resolution
P1: Contents/MacOS drop	Resolved ✅	Verified false positive — modules never placed there
P2: unnecessary .clone()	Resolved ✅	Fixed in faa6c6e

[ErikBjare]

Update the description to note 1dbc66b

[TimeToBuildBob]

Done — updated the description to note commit 1dbc66b and explain the new approach (build-time injection vs static resources in ).

[ErikBjare]

@TimeToBuildBob Do we still need this?

[TimeToBuildBob]

Good timing on the ping, Erik.

Short answer: the dirs.rs dynamic path detection is independently valuable and should still land. It fixes module discovery when the app isn't at /Applications/ActivityWatch.app — that's any user who keeps it in ~/Applications/ or runs from a downloaded DMG without dragging to Applications. That part doesn't depend on the tauri-native bundling decision.

The tauri-native bundling direction (replacing build_app_tauri.sh with cargo tauri build) is still blocked on the three evaluation questions in the PR body — they need macOS testing I can't do from my Linux container. The companion activitywatch-side change also hasn't shipped.

So: can land the dirs.rs changes separately (it's ~20 lines, no behavioral regression), or keep this draft open as a reference when you're ready to evaluate the bundler direction. Your call.

[TimeToBuildBob]

Promoted to ready for review.

This PR now only contains the dirs.rs dynamic bundle-path detection (18 insertions, 6 deletions) — the tauri.conf.json resource entries were already reverted in 1dbc66b. CI is green across all 7 checks.

Why this should land: the hardcoded /Applications/ActivityWatch.app paths fail whenever the app isn't at that exact location — ~/Applications/, CI artifacts running from /tmp, or a DMG that wasn't dragged to Applications. The current_exe() fallback detects the bundle layout dynamically and falls through cleanly on non-bundle builds (the resources_dir.exists() guard means it's a no-op outside .app bundles).

What this does NOT gate on: the larger question of replacing build_app_tauri.sh with cargo tauri build. That direction is documented in the PR body as a future path but isn't required for this change to be independently useful.

[greptile-apps]

Greptile Summary

This PR replaces the hardcoded /Applications/ActivityWatch.app/Contents/... module discovery paths on macOS with dynamic detection via std::env::current_exe(), walking up two directory levels from the running binary to find Contents/Resources/.

• src-tauri/src/dirs.rs: The macOS branch of get_discovery_paths() now uses current_exe() to locate Contents/Resources/modules/ and Contents/Resources/ dynamically, gated behind a resources_dir.exists() check so the code silently skips when not running inside a .app bundle (e.g. dev mode, CI runs).
• The previous .clone() finding from an earlier review is already resolved in this commit — resources_dir is moved on the second push, with no redundant clone.

Confidence Score: 5/5

Safe to merge — the dynamic path detection correctly handles standard .app bundles, macOS app translocation, and non-bundle invocations without introducing any regressions.

The change is narrow and well-guarded: resources_dir.exists() ensures the bundle paths are only added when the binary is actually running inside a .app bundle. The two-level parent walk correctly resolves to Contents/Resources for any install location, including translocated apps. The graceful if let Ok(...) wrapping means a failed current_exe() call silently skips bundle detection rather than panicking.

No files require special attention.

Important Files Changed

Filename	Overview
src-tauri/src/dirs.rs	Replaces two hardcoded macOS bundle paths with dynamic exe-relative detection; logic is correct for standard .app bundles, app translocation, and non-bundle (dev) invocations.

Flowchart

%%{init: {'theme': 'neutral'}}%%
flowchart TD
    A[get_discovery_paths macOS] --> B[Push ~/aw-modules]
    B --> C{current_exe ok?}
    C -- No --> Z[Return paths]
    C -- Yes --> D[exe: Contents/MacOS/aw-tauri]
    D --> E[parent: Contents/MacOS]
    E --> F[parent.parent: Contents]
    F --> G[resources_dir: Contents/Resources]
    G --> H{resources_dir exists?}
    H -- No --> Z
    H -- Yes --> I[Push resources_dir/modules]
    I --> J[Push resources_dir]
    J --> Z

Loading

%%{init: {'theme': 'base', 'themeVariables': {"darkMode": true, "background": "#0d1117", "primaryColor": "#21262d", "primaryTextColor": "#e6edf3", "primaryBorderColor": "#8b949e", "lineColor": "#8b949e", "textColor": "#e6edf3", "edgeLabelBackground": "#161b22", "actorBkg": "#21262d", "actorBorder": "#8b949e", "actorTextColor": "#e6edf3", "actorLineColor": "#8b949e", "signalColor": "#8b949e", "signalTextColor": "#e6edf3", "noteBkgColor": "#373320", "noteBorderColor": "#d4a72c", "noteTextColor": "#f0e6c0", "labelBoxBkgColor": "#21262d", "labelBoxBorderColor": "#8b949e", "labelTextColor": "#e6edf3", "loopTextColor": "#e6edf3", "activationBkgColor": "#30363d", "activationBorderColor": "#8b949e"}}}%%
flowchart TD
    A[get_discovery_paths macOS] --> B[Push ~/aw-modules]
    B --> C{current_exe ok?}
    C -- No --> Z[Return paths]
    C -- Yes --> D[exe: Contents/MacOS/aw-tauri]
    D --> E[parent: Contents/MacOS]
    E --> F[parent.parent: Contents]
    F --> G[resources_dir: Contents/Resources]
    G --> H{resources_dir exists?}
    H -- No --> Z
    H -- Yes --> I[Push resources_dir/modules]
    I --> J[Push resources_dir]
    J --> Z

Loading

_{Reviews (2): Last reviewed commit: "fix: remove unnecessary .clone() on reso..." | Re-trigger Greptile}

[TimeToBuildBob]

Greptile P1: Contents/MacOS path drop — verified false positive

I verified against the actual build_app_tauri.sh at https://github.com/ActivityWatch/activitywatch/blob/master/scripts/package/build_app_tauri.sh:

mkdir -p "dist/${APP_NAME}.app/Contents/"{MacOS,Resources}

# aw-tauri goes to MacOS/
cp "dist/activitywatch/aw-tauri" "dist/${APP_NAME}.app/Contents/MacOS/aw-tauri"

# All modules go to Resources/<component_name>/
for component in dist/activitywatch/*/; do
    if [ -d "$component" ]; then
        component_name=$(basename "$component")
        cp -r "$component"/* "dist/${APP_NAME}.app/Contents/Resources/$component_name/"
    fi
done

Key findings:

• Contents/MacOS/ only contains the aw-tauri executable itself
• All modules (aw-server-rust, aw-watcher-*, aw-notify) go to Contents/Resources/<name>/
• The old hardcoded Contents/MacOS path was effectively dead code for module discovery — no module has ever been placed there

So dropping Contents/MacOS from the dynamic discovery paths is correct and safe. The Resources/ path my code adds covers the actual legacy layout, and Resources/modules/ covers the future Tauri-native layout.

No code change needed. This finding is resolved — confirmed false positive.

[TimeToBuildBob]

@greptileai review

[TimeToBuildBob]

All checks have been completed:

• ✅ CI: 7/7 checks green (clippy, format, release on macOS/Ubuntu/Windows)
• ✅ Greptile: 5/5 confidence, safe to merge
• ✅ Erik's question answered (2026-06-29)

Ready for merge. (I lack permissions on this repo.)