wiredInPackages is out of date and depends on GHC version

[chreekat]

GHC's wired-in packages are currently

https://gitlab.haskell.org/ghc/ghc/-/blob/master/compiler/GHC/Unit/Types.hs#L635-643

wiredInUnitIds =
   [ primUnitId
   , bignumUnitId
   , ghcInternalUnitId
   , baseUnitId
   , rtsUnitId
   , thUnitId
   , experimentalUnitId
   ]

curator and stack both have different lists.

Curator:

https://github.com/commercialhaskell/curator/blob/master/src/Curator/Snapshot.hs#L565-L580

wiredInGhcPackages =
    Set.fromList
        [ "ghc-prim"
        , "integer-gmp"
        , "integer-simple"
        , "base"
        , "rts"
        , "template-haskell"
        , "dph-seq"
        , "dph-par"
        , "ghc"
        , "interactive"
        ]

Stack: commercialhaskell/stack#6558

I have no idea what effect this has on Stack or Stackage snapshots.

[bergmark]

I don't know why stack needs the list, seems odd if it wouldn't tie it to GHC versions.

For curator, I think:

a ghc-wired package missing in curator means we may upgrade it and that can break snapshots - but perhaps that would also break the creation of the snapshots since we build with stack. If it's missing in ghc it means that we won't upgrade them in snapshots even if we have to - so that's less of an issue.

I'm not sure what actual issues it may cause... we should keep it up-to-date

[chreekat]

Yeah looks like you wouldn't be able to specify such a package in a snapshot:

        let isWiredIn pn _ = pn `Set.member` wiredInGhcPackages
            (wiredIn, packages) =
              Map.partitionWithKey isWiredIn (Pantry.snapshotPackages snapshot)
        if not (Map.null wiredIn)
        then do
          let errMsg = "GHC wired-in package can not be overriden"
          pure $ Map.map (const [OtherError errMsg]) wiredIn

src/Curator/Snapshot:192

[mpilgrem]

As wired-in packages are GHC boot packages, I think they should not be included directly in snapshots. I've done some spring cleaning on Stack's list.

[mpilgrem]

@bergmark, Stack will not create a project with the same name as a wired-in package. For example:

❯ stack new rts

Error: [S-5682]
       Stack declined to create a new directory for project rts, as
       package rts is 'wired-in' to a version of GHC. That can cause
       build errors.

       The names blocked by Stack are: base, dph-par, dph-seq, ghc,
       ghc-bignum, ghc-prim, integer-gmp, integer-simple, interactive,
       rts and template-haskell.

[chreekat]

Sort of related haskell/cabal#9669

[TeofilC]

See also: haskell/cabal#10087

GHC-9.12 is likely to not wire-in template-haskell and base.

[chreekat]

Indeed, it looks like 9.12 has

wiredInUnitIds :: [UnitId]
wiredInUnitIds =
   [ primUnitId
   , bignumUnitId
   , ghcInternalUnitId
   , rtsUnitId
   ]

and HEAD (9.14?) has

wiredInUnitIds :: [UnitId]
wiredInUnitIds =
   [ ghcInternalUnitId
   , rtsUnitId
   ]

That's remarkable!

I suppose the real-world implications for Stackage are small, since it's almost always likely that snapshots will include the versions of core packages that are distributed with GHC, whether or not they are technically reinstallable.

Stack, however, would probably benefit from letting people reinstall such reinstallable packages.

[TeofilC]

Indeed that's right! I'm excited for being able to do something like take a stackage snapshot and just switch out template-haskell to be the version in the next GHC and see what breaks.

I have also created a ticket to track this for stack here: commercialhaskell/stack#6749

[juhp]

I think for Stackage, we basically don't "touch" (replace) any core (boot) libraries anymore for a long time, so I am not sure the "wiredIn" logic is that important or useful anymore in curator: on the other hand better detection of core libs would be good and would prevent us tripping over them.

[mpilgrem]

Is base not wired-in/magic for GHC 9.12.1?

If that were the case, I would have expected it to be mentioned somewhere in: https://downloads.haskell.org/ghc/latest/docs/users_guide/9.12.1-notes.html - and I can't see any mention.

On the other hand, while base.cabal for base-4.20.1.0 has:

    -- We need to set the unit id to base (without a version number)
    -- as it's magic.
    ghc-options: -this-unit-id base

but that is absent from base.cabal for base-4.21.0.0.

[TeofilC]

Is base not wired-in/magic for GHC 9.12.1?

Yep that's right. That really should've gone into the release notes, but it seems to have been left out.

See: https://gitlab.haskell.org/ghc/ghc/-/merge_requests/13200

[mpilgrem]

Stack currently warns (it is only a warning):

    when hasBaseInDeps $
      prettyWarn $
           fillSep
             [ flow "You are trying to upgrade or downgrade the"
             , style Current "base"
             , flow "package, which is almost certainly not what you really \
                    \want. Please, consider using another GHC version if you \
                    \need a certain version of"
             , style Current "base" <> ","
             , flow "or removing"
             , style Current "base"
             , flow "as an"
             , style Shell "extra-deps" <> "."
             , flow "For further information, see"
             , style Url "https://github.com/commercialhaskell/stack/issues/3940" <> "."
             ]
        <> line

I'll see what happens if I build using GHC 9.12.2 and a different version of base as an extra-dep ...

[mpilgrem]

So, I tried:

# stack.yaml
snapshot: nightly-2025-08-07 # GHC 9.12.2

extra-deps:
- base-4.20.1.0 # Override the GHC base boot package

and got (extracts):

 In the dependencies for base-4.20.1.0:
         * ghc-internal must match >=9.1002 && <9.1003, but ghc-internal-9.1202.0 is in the Stack configuration (latest matching version is 9.1002.0).
       The above is/are needed due to testCurator40-0.1.0.0 -> base-4.20.1.0

ghc-internal is wired-in/magic, so downgrading to a published base would not appear to be an option.

base-4.21.0.0 has build-depends: ghc-internal == 9.1201.*.

So, I suppose, what I need to experiement with is a local, patched, version of base-4.21.0.0.