Open avsm opened 11 years ago
This is a duplicate of #181, so closing the issue.
Not a formal request to re-open but since we collectively lost a few hours with @kit-ty-kate and a newcomer on https://github.com/ocaml/ocamlfind/issues/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®.
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? https://github.com/ocaml/opam/blob/800dc5be9a51a14c3a1f35bfc08d914930ab866f/src/client/opamAction.ml#L525
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.
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 https://github.com/ocaml/opam/issues/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.
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
.
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:
build-env:
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
Adding issues that are relevant to a possible future implementation of this:
we'll update this comment to avoid spamming
A lot of people seem to trip up on missing
ocaml-native-compilers
orcamlp4-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 (asbrew 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.