plan.json doesn't include compiler id.

[phadej]

Since some version of cabal-install, the locations of ghc-specific store take "project unit id" (e.g. ,("Project Unit Id","ghc-9.10.1-69c3")) into account. So it's not store/ghc-9.10.1 but store/ghc-9.10.1-69c3). However this information is absent from plan.json. plan.json contains just a version as compiler-id:

% python3 -m json.tool dist-newstyle/cache/plan.json|less
{
    "cabal-version": "3.14.1.1",
    "cabal-lib-version": "3.14.1.1",
    "compiler-id": "ghc-9.10.1",
    "os": "linux",
    "arch": "x86_64",
    "install-plan": [
...

Therefore tools (e.g. cabal-plan) which traverse the plan.json but also information in the store (e.g. license files), cannot do this anymore without also somehow finding the corresponding GHC (which can be anywhere, that's the point of an additional few bits - to disambiguate different GHC builds even with the same main version).

[mpickering]

In general it doesn't seem correct to assume that a package in the build plan comes from the store. It may also come from a package database given by package-db or the global package database.

Perhaps it would be better in future to store the LICENSE information in the plan.json directly, if this becomes a problem.

For now I will just expose the store-dir from the plan.json.

[mpickering]

@phadej Please let me know if this patch will solve your problem. #10845

[phadej]

@mpickering i think it does, but I also think it does too much as I told in private.

[phadej]

In general it doesn't seem correct to assume that a package in the build plan comes from the store. It may also come from a package database given by package-db or the global package database.

plan.json specifies when package in the plan comes from global db.
--package-db is undefined behavior in v2-build; even if it does something, it would break store's consistency.

Perhaps it would be better in future to store the LICENSE information in the plan.json directly, if this becomes a problem.

Please no, plan.json is just a plan, not contents.

For now I will just expose the store-dir from the plan.json.

Store directory is not plan. It also is directly in conflict with any effort making store relocatable.

[mpickering]

I think you are referring to the assumption that the global db (and any package databases specified with --package-db) are immutable. That isn't kept track of very well at the moment but perhaps you could record a hash of each package database you are using rather than just the path to it. If you start mutating the global package database then yes you will corrupt the store.

For now I will expose the "abi" field of the compiler into the plan.json and not address this other issue with attempting to recreate store paths from the plan.json file. It's noted on this ticket that use-case is not robust in all situations.