haskell / haskell/cabal

InstalledPackageInfo mega issue

Open
#8,967 5 comments 3 reactions 0 assignees View on GitHub
meta: tracking re: installed-package-info
Dominant language
Haskell
Stars
1.7k
Forks
750
Avg merge
4d 3h
Merged PRs (30d)
28

Description

There are a bunch of issues and PRs calling for adding more information to InstalledPackageInfo. I thought it would be a good idea to collect them here with a short summary so we can have better visbility and, if needed, discuss the bigger picture.

- #8702 by @bgamari. The solver does not know what flags have been used to compile an installed package, and it won't recompile an installed package even if we request it with different flags.
- #8701 by @bgamari. Cabal should use a separate field for `extra-bundled-libraries` as `hsLibraries` is deemed inapproriate.
- #8624 and #8696 by @bairyn. Similar to the first issue, solver does not know about artifact and could end up choosing an installed package that is missing some files (I admit I don't have a good understanding of this issue, please correct me if I botched this summary).
- #6039 by @fgaz. Sublibraries are installed as separate packagedb entries, and the solver has no information to group them back together into a coherent source package configuration. This causes the solver to always reject and recompile installed packages that provide public sublibraries (as the installed package is seen as missing the sublibrary)
- #5116 by @hvr. It suggests adding something to distinguish two GHC HEAD with the same version. Not sure whether this is still relevant.
- #1506 by @23Skidoo. It suggests adding information about cabal file revisions to InstalledPackageInfo, deemed a bad idea by @dcoutts and led to #3909 which was implemeted in #8534. I think this can just be closed.

AFAIU Changing InstalledPackageInfo requires some level of coordination with GHC since ghc-pkg uses Cabal to read the files and distill them into a GHC specific version. What is the process to make changes to InstalledPackageInfo?

Is it a good idea to keep adding cabal specific things to `InstalledPackageInfo`? Other tools might install packages in packagedb.

Should cabal install have its own database?

Should we have a clear distinction between ghc fields and tool specific fields?

In #8702 @bgamari refers to "non-normative" fields (which I have not found any documentation for) and suggests a syntax for fields ghc-pkg will automatically ignore (`x-field`).

Ping spamming @ulysses4ever @fgaz @Mikolaj @gbaz @hsyl20 and others (apologies in advance).

Contributor guide

Open the contributing guide

Assessment

This issue has not been assessed yet.

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.