source-hash should display hash of installed version

[Khady]

When a package is installed from a VCS like git, a source-hash field is displayed by opam show PKG. This hash is the hash of the last commit cloned by opam. It is not the hash of the commit used to install the package. This is miss-leading. Pretty often I run opam update without upgrading. After that it is complicated to know what version of the package is actually installed. I think it would be better to displayed the installed version.

Here is a simple scenario showing the confusing case:

$ ls
demo.opam
$ cat demo.opam 
opam-version: "2.0"
name: "demo"
version: "0.1"
synopsis: "demo"
description: """
demo
"""
maintainer: "Ahrefs <github@ahrefs.com>"
authors: "Ahrefs <github@ahrefs.com>"
homepage: "https://github.com/ahrefs/demo"
bug-reports: "https://github.com/ahrefs/demo/issues"
depends: []
build: ["dune" "build" "-p" name]
$ git init
Initialized empty Git repository in /tmp/opam/g/.git/
$ git add demo.opam 
$ git ci -am "1"
[master (root-commit) 70798f0] 1
 1 file changed, 13 insertions(+)
 create mode 100644 demo.opam
$ opam pin add demo -k git .
Package demo does not exist, create as a NEW package? [Y/n] y
[demo.~dev] synchronised from git+file:///tmp/opam/g#master
[WARNING] Failed checks on demo package definition from source at git+file:///tmp/opam/g#master:
  warning 47: Synopsis should start with a capital and not end with a dot
demo is now pinned to git+file:///tmp/opam/g#master (version 0.1)

The following actions will be performed:
  ∗ install demo 0.1*
Do you want to continue? [Y/n] y

<><> Processing actions <><><><><><><><><><><><><><><><><><><><><><><><><><><><>
∗ installed demo.0.1
Done.
$ opam show demo

<><> demo: information on all versions ><><><><><><><><><><><><><><><><><><><><>
name                   demo
all-installed-versions 0.1 [tools]
all-versions           0.1

<><> Version-specific details <><><><><><><><><><><><><><><><><><><><><><><><><>
version      0.1
pin          git+file:///tmp/opam/g#master
source-hash  70798f01
url.src:     "git+file:///tmp/opam/g#master"
homepage:    "https://github.com/ahrefs/demo"
bug-reports: "https://github.com/ahrefs/demo/issues"
authors:     "Ahrefs <github@ahrefs.com>"
maintainer:  "Ahrefs <github@ahrefs.com>"
synopsis     demo
description  demo
$ touch new
$ git add new
$ git ci -am "2"
[master d8ce25f] 2
 1 file changed, 0 insertions(+), 0 deletions(-)
 create mode 100644 new
$ opam update demo

<><> Synchronising development packages <><><><><><><><><><><><><><><><><><><><>
[demo.0.1] synchronised from git+file:///tmp/opam/g#master
Now run 'opam upgrade' to apply any package updates.
$ opam show demo

<><> demo: information on all versions ><><><><><><><><><><><><><><><><><><><><>
name                   demo
all-installed-versions 0.1 [tools]
all-versions           0.1

<><> Version-specific details <><><><><><><><><><><><><><><><><><><><><><><><><>
version      0.1
pin          git+file:///tmp/opam/g#master
source-hash  d8ce25f3
url.src:     "git+file:///tmp/opam/g#master"
homepage:    "https://github.com/ahrefs/demo"
bug-reports: "https://github.com/ahrefs/demo/issues"
authors:     "Ahrefs <github@ahrefs.com>"
maintainer:  "Ahrefs <github@ahrefs.com>"
synopsis     demo
description  demo
$ opam upgrade demo

<><> Synchronising pinned packages ><><><><><><><><><><><><><><><><><><><><><><>
[demo.0.1] no changes from git+file:///tmp/opam/g#master

The following actions will be performed:
  ↻ recompile demo 0.1*

<><> Processing actions <><><><><><><><><><><><><><><><><><><><><><><><><><><><>
⊘ removed   demo.0.1
∗ installed demo.0.1
Done.
$ opam show demo

<><> demo: information on all versions ><><><><><><><><><><><><><><><><><><><><>
name                   demo
all-installed-versions 0.1 [tools]
all-versions           0.1

<><> Version-specific details <><><><><><><><><><><><><><><><><><><><><><><><><>
version      0.1
pin          git+file:///tmp/opam/g#master
source-hash  d8ce25f3
url.src:     "git+file:///tmp/opam/g#master"
homepage:    "https://github.com/ahrefs/demo"
bug-reports: "https://github.com/ahrefs/demo/issues"
authors:     "Ahrefs <github@ahrefs.com>"
maintainer:  "Ahrefs <github@ahrefs.com>"
synopsis     demo
description  demo

[ygrek]

ftr https://www.bountysource.com/issues/63989495-source-hash-should-display-hash-of-installed-version

[kstuart]

FYI: from what I can see opam show displays information from the last updated definition (opam update), so if for example you committed changes to the version or description in demo.opam and opam updated that, opam show would reflect those changes.

The documentation for opam show does say it displays information about the installed version, but that doesn't appear to be the case.

[Khady]

I got bitten by this problem once again. This is a source of frustration at least once a month I would say.

[ygrek]

ftr per the new bountysource terms the bounty will expire on Dec 20 2020 and bountysource will retain the money (ref https://help.nextcloud.com/t/dont-use-bountysource-anymore/84943 ), so if somebody wants to work on this soon that would be nice

[ed-commits]

I had a look into this. It's not completely clear to me how this should be implemented.

This chunk of code

opam/src/client/opamListCommand.ml

Line 561 in b651400

| Source_hash ->

gets a source hash from the (wrong commit of the) repository when opam list is called. The correct repository doesn't seem to exist in ~/.opam.

On the other hand the fields in https://github.com/ocaml/opam/blob/master/src/client/opamListCommand.ml#L742 are extracted from the correct opam file for that version of the package.

So I was considering a change that would use an x-source-hash field, storing the source hash into the opam file when it's added and updated rather than when opam list is called. I couldn't work out where in the code this operation would go and I am not sure if adding data to opam files is desirable.

Any input on a correct strategy for fixing this issue?

[rjbou]

There is several ways to integrate that :

• Add an x- field in the internally stored pinned opam file : this results to adding a field in the opam file, plus x- fields were not meant primarily to be used by opam itself (even if we did it in recursive pinning, to avoid any opam file change)
• Add a pinned opam package -> source hash field in the switch-state : here we add a field in the switch-state file
• Add a new file in the internal directory where opam stores pinned opamfiles, that contains that hash : here we change opam internals layout
  The last one is the least invasive, but it breaks usual opam workflow.