Environment variables for host paths: one naming convention

[decay71]

@Simon-CR @Tareku99 you are both adding environment variables for host
paths right now, from two directions: Simon in #141 (generic Klipper
hosts, path discovery in ace.py and the backend), Nicola in the
paxx-managed-package branch (bind-mounted install, PAXX owns the
paths). Let's agree on one list before either lands.

What exists on main today (backend and updater), all with the
MULTIACE_ prefix:
MULTIACE_DIR, MULTIACE_CFG_PATH, MULTIACE_FRONTEND_DIR,
MULTIACE_UPDATE_REPO, MULTIACE_UPDATE_URL_BASE, MULTIACE_UPDATE_PRERELEASE
(plus a few runtime knobs like MULTIACE_LANGUAGE, MULTIACE_WS_DEBUG).

Nicola's branch adds, same prefix:
MULTIACE_ROOT, MULTIACE_CONFIG_DIR, MULTIACE_WEB_DIR, MULTIACE_MANAGED,
MULTIACE_MANAGED_MARKER, MULTIACE_DISABLE_UPDATES,
MULTIACE_IGNORE_FIRMWARE_MANAGED.

#141 adds, without prefix:
KLIPPER_CONFIG_DIR, PRINTER_DATA.

Proposal:

1. Everything multiACE reads keeps the MULTIACE_ prefix. The two names
   in feat(transport): two-tier transport liveness watchdog, dynamic path resolution, and reactor pause fix #141 become MULTIACE_CONFIG_DIR (already defined by Nicola, same
   meaning: the directory holding printer.cfg) and MULTIACE_PRINTER_DATA.
2. One variable per path, read by every process that needs it (ace.py
   in Klipper, the web backend, the shell scripts). No second name for
   the same directory.
3. Defaults stay the U1 paths, so a printer without any of these set
   behaves exactly as today.
4. The list lives in one place in the repo (docs or a comment block in
   the backend) so the next contributor finds it.

Simon, Nicola: does that work for you, and is anything missing from the
list? Once you agree I'll merge the path half of #141 with the renamed
variables and Nicola's package can rely on the same names.

Dirk

[decay71]

Update: this moved faster than the text above. #141 is merged, and #148
renamed the two variables, so main now reads MULTIACE_CONFIG_DIR and
MULTIACE_PRINTER_DATA (ace.py, at Klipper start). Points 1 to 3 are
therefore already in the code; this issue is now only the shared list
and the two remaining questions:

Nicola: the package needs to set MULTIACE_CONFIG_DIR and
MULTIACE_PRINTER_DATA for the Klipper process too, not only for the
backend. Does your init path reach S60klipper's environment?

Simon: if the generic host needs anything beyond those two, add it
here first so the names stay in one place.

[Tareku99]

Sounds good, I am working on #151, I only have today/tomorrow so I am putting some things together before I leave for travels again. I did some very small testing and it seems promising.

I also moved the implementation paxx12-snapmaker-u1/SnapmakerU1-Extended-Firmware#738 to mods/ like paxx mentioned.

For PR 151, take a peak at it and lmk if you see any immediate issues

[Simon-CR]

Thanks Dirk (@decay71). I've reviewed the standardization in PR #148, and MULTIACE_CONFIG_DIR and MULTIACE_PRINTER_DATA completely satisfy the path requirements for generic Klipper architectures. We don't foresee needing any additional host-level environment variables at this time:

1. Complete Coverage: These two roots cleanly separate config and runtime data across standard and non-standard host layouts (including Docker deployments where configs are read-only and data mounts are decoupled).
2. Zero Additional Variables Needed: Auxiliary paths (virtual SD card, Moonraker sockets) are managed natively by Klipper and Moonraker launch arguments, and persistent storage (persistent/multiace_spools.json) derives directly from config_dir.
3. Out-of-the-Box Zero-Config: On standard generic installs (e.g. KIAUH) where neither env var is defined, ace.py's automatic fallback via printer.get_start_args()['config_file'] resolves ~/printer_data/config and ~/printer_data seamlessly with zero manual configuration.

One minor suggestion to complete the alignment: we should update multiace/web/backend/main.py (_CFG_DIR) to also read MULTIACE_CONFIG_DIR as its first preference, ensuring both Klipper (ace.py) and the web backend share the exact same environment convention. Happy to spin up a quick PR for that if it works for you and @Tareku99.

[decay71]

Thanks Simon, good catch. You're right, the backend still resolves _CFG_DIR on its own, so on a host with a custom config dir it would read and write snapshots and slot overrides somewhere other than Klipper does.

Yes please, go ahead with the PR: MULTIACE_CONFIG_DIR as first preference for _CFG_DIR, then the existing fallbacks. While you're in there, the two hardcoded printer_data/config/tools/post_process_virtual_toolheads.py lookups in main.py should follow _CFG_DIR as well. MULTIACE_CFG_PATH can stay as the more specific override on top.

[Simon-CR]

Opened PR #153 covering this:

• Prioritizes MULTIACE_CONFIG_DIR for _CFG_DIR in multiace/web/backend/main.py, keeping existing fallbacks and preserving MULTIACE_CFG_PATH as the specific per-file override.
• Aligns the post-processor script lookups in _load_post_processor() and preflight_pysrc() to resolve via Path(_CFG_DIR) / "tools" / "post_process_virtual_toolheads.py".
• Includes a standalone self-check test in tests/backend_config_dir_selfcheck.py validating override precedence, fallbacks, and tool resolution.

[Simon-CR]

Submitted PR #153 with the backend MULTIACE_CONFIG_DIR preference and updated _CFG_DIR tool lookups. Ready for review when convenient!

[decay71]

For the record, #153 adds a third, optional one:

MULTIACE_CONFIG_DIR: Klipper config root (ace.py, web backend)
MULTIACE_PRINTER_DATA: printer_data root (ace.py)
MULTIACE_POST_PROCESS_SCRIPT: optional path to post_process_virtual_toolheads.py (web backend); by default it follows MULTIACE_CONFIG_DIR/tools/

[Tareku99]

Thanks Dirk, that third optional variable makes sense. I checked the PAXX startup path: our Klipper hook is sourced by S60klipper, so MULTIACE_CONFIG_DIR and MULTIACE_PRINTER_DATA reach Klipper. The multiACE web service gets those two as well.

The remaining PAXX change is to pass MULTIACE_POST_PROCESS_SCRIPT, pointing to the helper inside the pinned package. I’ll make that change in PAXX PR #738 after multiACE PR #153 is merged, then test the preflight on the printer. After that I can switch the pin to the regular managed release once the archive and checksum are published.

I saw the note about removing the duplicate test in PR #153. @Simon-CR, once that’s done, I’ll update the PAXX side. @decay71, please let me know when the regular release is ready so I can update the pin.

[Tareku99]

I am not too sure if I can finish this up on paxx side, I will be starting travel tomorrow so please feel free to take over that branch to update the pin version. I have done some testing of basic tasks, and it seems to be working well! Did not print anything yet but if multiAce works solo, it should work here as well just fine :)

[decay71]

Thanks Nicola, and safe travels. I'll take it from here: once #153 is merged and the next release is tested and out, I'll update the pin, checksum and MULTIACE_POST_PROCESS_SCRIPT in #738.

Dirk