staversion fails because the list of GHC core packages is out of date for some new GHC versions

[ulidtko]

Hi Toshio Ito! I hope you're well. Thanks for publishing this tool — much appreciated. 🙇‍♂️

Upon installing, I found that the most basic usage — querying available Stackage package versions a-la apt-cache show — is no longer functional. Specifically, I tried querying cabal-install, lens, conduit — on resolvers lts-18.17, lts-17.11. All variations produce the same ERROR, accompanied with 2 scary warnings about "build plan files" which I frankly fail to understand.

For example:

$ staversion --resolver lts-18.17 lens
[warn] Loading build plan for package resolver 'lts-18.17' failed: /home/ulidtko/.stack/build-plan/lts-18.17.yaml not found.
/home/ulidtko/.stack/build-plan/lts-18.17.yaml: openBinaryFile: does not exist (No such file or directory)
[warn] Loading build plan for package resolver 'lts-18.17' failed: /home/ulidtko/.stack/build-plan/lts-18.17.yaml not found.
/home/ulidtko/.stack/build-plan/lts-18.17.yaml: openBinaryFile: does not exist (No such file or directory)
[error] Failed to load build plan: No CoreBuildPlanMap for compiler Compiler {compilerName = "ghc", compilerVersion = CVNumbered (mkVersion [8,10,7])}
------ lts-18.17
-- lens ERROR

I installed the latest available version, staversion-0.2.4.1 — using stack install --local-bin-path ~/.local/bin staversion.

My stack tool is Version 2.7.3, Git revision 7927a3aec32e2b2e5e4fb5be76d0d50eddcc197f currently.

Hope that helps. Please drop me a line if you need more information to fix this; I'll also have it as an honor to validate your solution once it's ready. Best wishes!

[debug-ito]

Thanks for making such a detailed bug report!

First of all, the "No such file or directory" warning is totally normal. You can ignore that. (Maybe it should not be a warning in the first place.)

The error is because staversion failed to get the list of package versions bundled with ghc-8.10.7, which is used in lts-18.17. staversion loads that file from https://gitlab.haskell.org/bgamari/ghc-utils/-/raw/master/library-versions/pkg_versions.txt . Unfortunately, the list is not up to date. It doesn't have the package version list for ghc-8.10.7 yet. There are multiple merge-requests to update the list, but it often takes time to merge.

If you have better place to get the correct and up-to-date list of GHC core packages, please let me know. Or, maybe the best solution is stop depending on external lists, and staversion maintains its own list of GHC core packages. However, I'm afraid I don't have time to maintain such a list by myself.

[ulidtko]

@debug-ito hi again... Can't you leverage the stack.sqlite3 to extract the same information?..

Or rather, the pantry.sqlite3 — this DB, I believe, contains a complete description of stackage snapshot.

[ulidtko]

OK, so I'm still scratching my head with all these snapshot layers business 🤔 — but here's a query against pantry.sqlite3 which returns versions for hackage packages at least:

select p.name, v.version
	from package_name p
		join hackage_cabal hc on (hc.name = p.id)
		join tree t on (hc.tree = t.id)
		join version v on (v.id = t.version)
	where p.name = 'foobar'; -- https://hackage.haskell.org/package/foobar-0.1.0.0

Demo:

The readme here is pretty useful to navigate stack source code: https://github.com/commercialhaskell/pantry

PS: about the warning, I'd perhaps demote it into a debug log — to be visible in --verbose calls but no worse.

[debug-ito]

Thanks for great analysis.

I'll look into it, but probably my time for it is quite limited. So, please be patient.

[debug-ito]

Design candidate: add a new option such as --pkg-versions-file to specify the local path to the pkg_versions.txt. That way, users can download the pkg_versions.txt from those unmerged merge-requests (such as this) and specify it in the option.

BTW, personally I use staversion less often than before, because I use stack less often. So, I'm afraid I'm not so motivated to fix this problem, considering how limited my time is.