Manage MUIOGO's environment separately from the OG models

[SeaCelo]

MUIOGO runs in its own environment. The OG country models run in theirs, installed by their own installers (#470). These stay separate: MUIOGO doesn't install or import OG-Core, and the OG model version is whatever the user has in that environment.

This issue covers how we manage MUIOGO's own environment. The main open question is whether to move MUIOGO's installer to uv — OG-Core and OG-ETH already use it, it would give us reproducible installs and drop the "install Python yourself first" step. Worth looking at, not decided; if we go ahead, the migration gets its own issue.

Related: the Python version pin (<3.13, from numpy) needs fixing so we can follow upstream and support newer Python — separate issue.

cc @Adityakushwaha2006

[SeaCelo]

Hey @utsinboots — would you be up for taking this on? It's self-contained and high-value.

What we want

A single-line installer for MUIOGO. Today a user has to install git, install Python, clone the repo, then run setup.bat/setup.sh. We want one command that does all of it from a clean machine:

• macOS / Linux: curl -fsSL https://raw.githubusercontent.com/EAPD-DRB/MUIOGO/main/scripts/install.sh | bash
• Windows: irm https://raw.githubusercontent.com/EAPD-DRB/MUIOGO/main/scripts/install.ps1 | iex

Same idea as Homebrew's installer or the OG-Core installer (scripts/install.sh + install.ps1) — use those as the bar for the experience, but this is MUIOGO's own installer, not a reuse of OG-Core's.

How it should work — two layers

1. Bootstrap (new): install git if missing → clone the repo → install uv → uv sync. uv is Astral's tool that installs Python and the dependencies in one step, so users no longer have to install Python first. This needs MUIOGO to become a uv project: move the deps from requirements.txt into a real [project] block in pyproject.toml and commit a uv.lock (pin Python to >=3.11,<3.13). That pin also sidesteps Fix the Python version ceiling so MUIOGO can support 3.13+ #473.
2. Platform setup (already exists — reuse it): the GLPK/CBC solver install, demo data, secret key, and verification already live in scripts/setup_dev.py and work. Keep that logic — just split it so it runs as a step after the env is built. Don't rewrite it.

Starting point: don't build from scratch — setup_dev.py is a solid base. Its reporting is genuinely nice (the per-step [PASS]/[FAIL]/[WARN] output, the verification checks, the Setup Summary at the end). Keep that style and extend it to cover the new bootstrap steps (git, uv, clone).

We specifically want a real git clone, not a downloaded zip, so users can git pull to update instead of re-downloading.

Installing git per platform

• Windows (your platform): winget install -e --id Git.Git --accept-package-agreements --accept-source-agreements. Fall back to the silent official installer (Git-…-64-bit.exe /VERYSILENT /NORESTART /SUPPRESSMSGBOXES /NOCANCEL /SP-) for machines without winget.
• Linux: detect the package manager (apt/dnf/pacman/zypper/apk) and install non-interactively with sudo.
• macOS: xcode-select --install (Command Line Tools — that's what provides git). Not Homebrew: installing brew triggers the same CLT install anyway, so it's just extra moving parts.

macOS notes — you're on Windows, so here are the mac details you can't easily verify yourself. (Don't worry about Mac testing — we'll handle that end.) A few things we worked out that aren't obvious:

• xcode-select --install opens a GUI dialog and returns immediately — it does not wait for the install to finish. You have to poll xcode-select -p until it succeeds before cloning.
• Don't detect git with command -v git. macOS ships a stub at /usr/bin/git that exists even when git isn't really installed, so it gives a false positive (and calling it pops the dialog). Use xcode-select -p to decide whether CLT is present.
• After CLT installs, git is at /usr/bin/git — already on PATH, so no PATH work on mac. (PATH does need handling for freshly-installed git on Windows and for uv — see constraints.)
• Handle the failure modes, since the CLT download is ~1 GB+ and user-driven: no network, user declines the dialog, interrupted, or just slow. Plan: check network first; poll with a generous timeout (~45–60 min) and a "still installing…" heartbeat so a slow-but-working install isn't killed; verify git --version actually works afterward; and make the whole installer safe to re-run so an interrupted install just resumes.

Hard constraints

• Additive-only. No rm -rf, no sudo deletes, no touching system paths. The installer only writes into its own locations (clone dir, venv, uv's ~/.local/bin, the solver dir). If CLT ends up broken, point the user to reinstall it from developer.apple.com — don't delete anything. For a half-finished clone, clone into a temp dir and move it into place on success rather than deleting.
• PATH: a freshly-installed git or uv won't be on PATH in the same shell session — call them by absolute path or re-exec. (setup_dev.py already does this for the CBC solver; same pattern.)
• Idempotent: safe to re-run; detect what's already there and skip it.
• Fail clean: on any failure, say what went wrong and what to do, and exit non-zero.

Scope

This is the developer/power-user source installer (the curl|bash one-liner). It's separate from the packaged end-user .exe/.app (the PyInstaller track, #394/#395) — don't fold them together.

Before coding, please post your planned approach here — the per-platform flow and how you'll split setup_dev.py — so we can sanity-check it first. Thanks!

[utsinboots]

Hi @SeaCelo, my planned approach:

Step 1: Migrate MUIOGO to uv-managed project
Move dependencies from requirements.txt into a [project] block in pyproject.toml, pin Python to >=3.11,<3.13, and commit uv.lock. Check files from OG-Core, OG-ETH.

Step 2: Add bootstrap installer (scripts/install.ps1 + scripts/install.sh) modeled on the OG-Core installer.

Step 3: For setup_dev.py:

• Keep the existing platform setup logic and [PASS]/[FAIL]/[WARN] reporting style intact
• Add a --platform-only flag, or equivalent split, so the bootstrap can invoke it after uv sync without re-running environment creation. No rewrites; additive only

Step 4: Follow the platform-specific Git installation flow (winget/silent installer on Windows, xcode-select on macOS, package manager detection on Linux).

I will work on my fork, test the changes there, and submit a PR.