opam config report: add the user's environment

[dbuenzli]

Following up on #3086 where @AltGr fished for further sanity checks in opam config report. I'd suggest to simply add to output the user's environment in the report: it seems the potential for problems from the user's environment is boundless. This could avoid a few message exchanges on error reports.

I would also suggest adding a --no-env option for users who care about the privacy of their environment.

[Drup]

Please don't. A lot of stuff can end up in your environment which are fine locally but shouldn't be disclosed, and it's very easy to just post the output of opam config report without noticing that you just disclosed an important piece of information. Divulging the environment by default is really not a good default.

[dbuenzli]

I won't fight too much for this so feel free to close it. But:

1. I personally rarely put things that shouldn't be disclosed in my environment, if only temporarily. The environment is not something I typically trust never to leak at some point.
2. The output could seperate the environment clearly from the rest with a warning so that c&p can be easily controlled not to include. it.

[AltGr]

I am not against including some part of the env, but the point of config report is to be short and to the point so as to be easily copy-pastable, and the env typically contains lots of completely irrelevant information (e.g. 61 vars on this host, some of them multiline, many of them pointing to sockets, or related to the graphical environment).

One possibility would be to include some of them, e.g. any *PATH variable, possibly OCAML*. What else could we need ? HOME or locale vars ? TERM ? Of course, this doesn't cover your case above, so may be beside the point. We also need to consider what we want to target with opam config report: it was initially designed to debug opam issues, not random build issues (not wanting to minimise the importance of the latter here, taking the time to help beginners with build issues as you do is extremely useful and I thank you for it)

A better option IMO, which is still on open discussion, would be to have opam call sub-commands with a sanitised environment, to limit these "boundless" problems at their root. This may be optional to begin with, but I am afraid it could otherwise also cause problems with many users purposefully using env variables and assuming they are passed through to opam.

[dbuenzli]

Yeah I don't think it's worth including a selection.

Another alternative would be to spit out the environment on increased opam verbosity which is something you usually ask on problems. But that would be even worse w.r.t. to @Drup's point, since there's usually so much information there that you won't bother looking at what you are posting.

[dbuenzli]

Let's not clutter the tracker with useless issues. Given the relatively cold response, I'll close this for now.