I’m trying to install pyml, and it keeps failing to find stdcompat. FWIW, I’m on a recent OpenSUSE Tumbleweed.
dfeuer@squirrel:~/src/potato> opam --version
2.0.7
dfeuer@squirrel:~/src/potato> opam switch create brand ocaml-base-compiler.4.10.2
<><> Gathering sources ><><><><><><><><><><><><><><><><><><><><><><><><><><><><>
[ocaml-base-compiler.4.10.2] found in cache
<><> Processing actions <><><><><><><><><><><><><><><><><><><><><><><><><><><><>
∗ installed base-bigarray.base
∗ installed base-threads.base
∗ installed base-unix.base
∗ installed ocaml-base-compiler.4.10.2
∗ installed ocaml-config.1
∗ installed ocaml.4.10.2
Done.
# Run eval $(opam env) to update the current shell environment
dfeuer@squirrel:~/src/potato> eval $(opam env)
dfeuer@squirrel:~/src/potato> opam install pyml
The following actions will be performed:
∗ install conf-m4 1 [required by ocamlfind]
∗ install ocamlfind 1.8.1 [required by pyml]
∗ install stdcompat 15 [required by pyml]
∗ install pyml 20210226
===== ∗ 4 =====
Do you want to continue? [Y/n] y
<><> Gathering sources ><><><><><><><><><><><><><><><><><><><><><><><><><><><><>
[ocamlfind.1.8.1] found in cache
[pyml.20210226] found in cache
[stdcompat.15] found in cache
<><> Processing actions <><><><><><><><><><><><><><><><><><><><><><><><><><><><>
∗ installed conf-m4.1
∗ installed ocamlfind.1.8.1
∗ installed stdcompat.15
[ERROR] The compilation of pyml failed at "/home/dfeuer/.opam/opam-init/hooks/sandbox.sh build make all pymltop PREFIX=/home/dfeuer/.opam/brand".
#=== ERROR while compiling pyml.20210226 ======================================#
# context 2.0.7 | linux/x86_64 | ocaml-base-compiler.4.10.2 | https://opam.ocaml.org#f2f68c82
# path ~/.opam/brand/.opam-switch/build/pyml.20210226
# command ~/.opam/opam-init/hooks/sandbox.sh build make all pymltop PREFIX=/home/dfeuer/.opam/brand
# exit-code 2
# env-file ~/.opam/log/pyml-15995-0f1b61.env
# output-file ~/.opam/log/pyml-15995-0f1b61.out
### output ###
# ocamlfind: Package `stdcompat' not found
# Makefile:76: *** stdcompat module not found: please specify the path with STDCOMPAT=.... Stop.
<><> Error report <><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><>
┌─ The following actions failed
│ λ build pyml 20210226
└─
┌─ The following changes have been performed
│ ∗ install conf-m4 1
│ ∗ install ocamlfind 1.8.1
│ ∗ install stdcompat 15
└─
The former state can be restored with:
opam switch import "/home/dfeuer/.opam/brand/.opam-switch/backup/state-20210311161208.export"
Just to check:
dfeuer@squirrel:~/src/potato> ocamlfind query stdcompat
ocamlfind: Package `stdcompat' not found
dfeuer@squirrel:~/src/potato> opam install stdcompat
[NOTE] Package stdcompat is already installed (current version is 15).
dfeuer@squirrel:~/src/potato> opam show stdcompat
<><> stdcompat: information on all versions <><><><><><><><><><><><><><><><><><>
name stdcompat
all-installed-versions 15 [/home/dfeuer/src/tezos testing-inst brand]
all-versions 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15
<><> Version-specific details <><><><><><><><><><><><><><><><><><><><><><><><><>
version 15
repository default
url.src: "https://github.com/thierry-martinez/stdcompat/releases/download/v15/stdcompat-15.tar.gz"
url.checksum: "sha512=1f4a9f98fa478360b8202bb5753a731d69fbafd7d964b96edefcc56100d78cdc5489faaf2c0bb1a4ee27949601a823ae3539f83f3ee4bf11bc2da18aea276899"
homepage: "https://github.com/thierry-martinez/stdcompat"
bug-reports: "https://github.com/thierry-martinez/stdcompat/issues"
dev-repo: "git+https://github.com/thierry-martinez/stdcompat.git"
authors: "Thierry Martinez <martinez@nsup.org>"
maintainer: "Thierry Martinez <martinez@nsup.org>"
license: "BSD-2-Clause"
depends: "ocaml" {>= "3.08"}
depopts: "result" "seq" "uchar" "ocamlfind"
synopsis Compatibility module for OCaml standard library
description Compatibility module for OCaml standard library allowing programs to use some recent additions to the OCaml standard library while
preserving the ability to be compiled on former versions of OCaml.
That produces a slew of info, none of which I know how to interpret. I’ve collected it in this gist; does it give you some clue as to what’s going wrong?
It seemed to have install its META file in /home/dfeuer/.opam/brand/lib64/stdcompat. IIRC The META is the one used by ocamlformat to get info about packages.
Can you check that the content of that file is somewhat similar to other META files in your opam folder?
Can you check whether other libraries are installed in lib64 or in lib? On my machine everything is on lib. I wonder if the install method of stdcompat picks up something different from your environment that would explain the different path it installs in?
Can you check what ocamlfind printconf outputs? Mines mention lib/ in its “Search path:”
One line of the configure output shows that it’s loading a configuration file from your distribution. This likely overrides the libdir configuration variable to use lib64 instead of lib. None of the OCaml tools support this convention, as far as I am aware.
You can try the command unset CONFIG_SITE; opam reinstall stdcompat and see if it works better.
@vlaviron: Wow… I had no idea that environment variable existed, let alone that it would affect OCaml installation. Unsetting it indeed fixes that! What do you suggest I do to make sure opam never sees that again?
Would you consider it a bug in the stdcompat packaging that it respects that environment variable? Or a bug in ocamlfind that it doesn’t look in lib64? Or something else? I’d like to prevent someone else from spending multiple days flailing at this silly problem.
I’m not sure honestly. I think the choice of stdcompat to use the autoconf tools is a bit unfortunate, the choice of your distro/environment to export CONFIG_SITE quite dangerous, and the support in the OCaml tools for lib64 could also be improved.
But it’s only a bug when you combine the three of them, so I’m not sure what’s the best thing to do here.
Maybe you could try submitting a bug report to stdcompat and see whether the maintainer has an opinion on that ? Then depending on the discussion there it may make sense to submit issues on other projects as well to involve more people in the discussion.
By a bizarre coincidence, about 24 hours ago I built a patch to drop the pyml → stdcompat dependency (as part of an effort to use it in an opam monorepo). Depending on the priorities of the maintainers, this might be an OK approach for this problem too. I’m also happy to contribute a switch to Dune-built shim libraries in pyml, since that covers my use-case.
@David_Feuer: I encourage you to submit issues on GitHub as @vlaviron suggests, and I’ll follow the discussion closely
Sorry for not having answered earlier and thank you very much for reporting! There are certainly things I have to fix to address this problem, either in pyml or stdcompat or both, but I don’t know what is the right thing(s) to do:
we can drop stdcompat dependency, but it will break compatibility with OCaml <4.06 (or we have to reproduce in pyml some parts of the work done in stdcompat, in particular for floatarrays); we can also rewrite things such that there is only dependency to stdcompat when OCaml is <4.06;
we can drop autotools usage in stdcompat: autotools is mainly used for preprocessing OCaml files for conditional compilation. There are probably better options, but I would prefer not to replace this autotools dependency with yet another dependency (but embedding a small ad-hoc preprocessor in stdcompat package itself can be an option);
I can unset CONFIG_SITE somewhere in stdcompat's Makefile.am if it can help (and if it is so, it will be the simplest, short-term solution): I will try to understand more how to do that!
If I’m not mistaken, CONFIG_SITE would have to be unset before configure is run. So in the Makefile I’m afraid it would be too late.
You might be able to patch your opam file to set the variable to the empty string though.
But ultimately I wouldn’t be surprised if the real problem is that CONFIG_SITE was exported. It looks like the kind of variable that can be set locally for overriding the default for a single command, but there is also a more robust mechanism to set a system-wide configuration that wouldn’t have interfered with opam and ocamlfind.
