From 4c560095ba4b0864821cac0bd5e34267df8b4a75 Mon Sep 17 00:00:00 2001 From: dmjio Date: Thu, 22 Oct 2026 16:50:17 -0700 Subject: [PATCH] miso update: write the new package list where every project reads it miso update ran "miso mcabal update" with CABALDIR set to $MISO_HOME/mcabal, but the child set CABALDIR again from the project it ran in (MISO_PROJECT, which this process had set). So the new Stackage list went to the project's .miso/mcabal, the old shared list was then copied back over it, and versions never moved, while it said "Updating the package list". The update now runs in $MISO_HOME/mcabal with MISO_PROJECT cleared, so the child uses the shared list. Checked with the built tool and a stand-in curl that serves a snapshot with split 9.9.9 (the shared list had split 0.1.0): before, both lists still had 0.1.0 and the snapshot was downloaded into the project's .miso/; now both have 9.9.9, downloaded into $MISO_HOME/mcabal. --- src/Miso/CLI/Deps.hs | 9 ++++++++- 1 file changed, 8 insertions(+), 1 deletion(-) diff --git a/src/Miso/CLI/Deps.hs b/src/Miso/CLI/Deps.hs index 13eaa65..5941c69 100644 --- a/src/Miso/CLI/Deps.hs +++ b/src/Miso/CLI/Deps.hs @@ -579,7 +579,14 @@ updateDeps cfg0 = do cfg <- withMiso cfg0 setupEnv info "Updating the package list" - withGlobalCabal (runSelf "mcabal update") + -- In $MISO_HOME, the package list every project shares. mcabal runs in + -- a child (miso mcabal), which sets CABALDIR again from the project it is + -- in: so not in the project, and without the MISO_PROJECT this process + -- set, or it wrote the new list to the project's .miso/ and the old one + -- was copied back over it. + global <- globalCabalDir + exe <- self + withGlobalCabal (run ("cd " ++ quote global ++ " && MISO_PROJECT= " ++ quote exe ++ " mcabal update")) old <- maybe [] id <$> readLock info ("Locking the dependencies in " ++ lockFile) new <- resolveTree False old cfg