opam doctor option

[avsm]

A lot of people seem to trip up on missing ocaml-native-compilers or camlp4-extra, and it's almost inevitable that something will fail in this situation.

Is it sensible to have an opam doctor command that would run some self-tests and issue warnings (as brew doctor does) ...? OPAM should still continue to work if these packages aren't installed, but some self-testing would help users identify obscure build failures more easily.

[samoht]

This is a duplicate of #181, so closing the issue.

[dbuenzli]

Not a formal request to re-open but since we collectively lost a few hours with @kit-ty-kate and a newcomer on ocaml/ocamlfind#40 it might still be a good idea to introduce that at some point.

Every now and then we get odd user setup that break stuff catastrophically.

It would be good to have a place to have to collect and check for these things since I personally tend to completely vaccuum them out of my brain.

On the top of my head just a few things I remember that are not a good idea®.

• Having . in your PATH
• On macOS having a gcc or binutils install that overrides xcode tools. 1, 2, 3, 4.
• CLICOLOR forced
• Have stuff in GREP_OPTIONS

[kit-ty-kate]

I’m not sure about the "opam doctor" option, but we definitely could do something about the unreasonable environment variables. We already scrub a couple of environment variables: https://opam.ocaml.org/doc/Manual.html#opamfield-build-env

Could you open a separate issue and/or open a PR to add those environment variables to this list?

opam/src/client/opamAction.ml

Line 525 in 800dc5b

"CDPATH", Eq, "", Some "shell env sanitization";

[philCryoport]

I'm the "newcomer" mentioned above. Boy was that a PITA to figure out that my OOTB oh-my-zsh or some tool I've installed that wrote to my .zshrc added CLICOLOR_FORCED=1

For those of us opam n00bs, please add opam doctor. The hours I lost debugging ocamlfind and topkg I really needed for something else. Thank you.

[dbuenzli]

I’m not sure about the "opam doctor" option, but we definitely could do something about the unreasonable environment variables.

That won't solve for example the binutils problem (and if you look at the cross references in this issue it's far from being uncommon #3650), nor the . in the PATH.

Btw. is there a command that allows to quickly check the build env in which a package will be built ? I didn't follow closely when opam sandboxing was introduced and I'm never exactly sure what gets picked up or not nowadays.

[rjbou]

It is a good idea for a plugin! Plus these checks don't need the opamlib (ftm).

On the sandbox, it was added in 2.0. For the build env check regarding the sandbox, you can run

$ .opam/opam-init/hooks/sandbox.sh build env

For the complete build env (sandbox + opam env), you can create a fake tiny package that have as build instruction env.

[dbuenzli]

It is a good idea for a plugin!

Not really. If you can't install anything you won't be able to install a plugin.

Also when you are trying to help someone asking to install more stuff always gets in the way.

For the complete build env (sandbox + opam env), you can create a fake tiny package that have as build instruction env.

Yes I have done that in the past but it's not really a solution:

1. Again it's a lot of work and instructions when you are trying to help someone, especially a newcomer.
2. You want to be able to quickly assess a given package's build environment and that includes what it added via build-env:

[mseri]

Another common issue with homebrew on mac is having both a rosetta x86_64 hombrew install and also a native arm64. In this case it is quite common to see random failures of the type "unavailable symbols for arechitecture XYZ" on libraries with cstubs or their dependencies

[kit-ty-kate]

Adding issues that are relevant to a possible future implementation of this:

• opam init doesn't initialise a switch #5807

we'll update this comment to avoid spamming