If this is an issue, it sounds like the best way to go about it is to open an issue in the opam bug tracker.
But I don’t quite understand the issue truth be told. I’d expect OPAM uses PATH by default and that’s also what I remember it was called when I used Windows, multiple decades ago. Why would it be called Path now and if it is case insensitive, why is it even a problem?
I don’t think this is an OPAM issue. It appears when running odig:
opan exec -- odig odoc mylib
Debugging this issue with the maintainer of odig led us to this issue:
odig is expectiong a “PATH” where in my opam environment it is a “Path” variable…
odig maintainer is well aware and will patch this, but since I see OPAM taking the name of the Path variable from thhe environment variable name…I thought there would be a mean to fix it directly in opam…
Yes. In fact any program that parses the result of Unix.environment and performs looks up itself maybe subject to such problem.
If you lookup variables with Sys.getenv you don’t run into the problem because the system call handles the caseless lookup. The reason why the underlying b0 build abstraction does not use the latter is because in a build system you want tight control over the environment(s).
Mostly already covered, but just to add that this would be a bad thing to “fix” in opam: the main thing opam does to the path is "PATH" += bin … i.e. it amends the existing variable, which is why it’s quite intentionally case-preserving. In particular:
Fair enough. By fix it in opam I had in mind replay the way opam retrieve environment variables to set its own, which could fix the issue if I rename the “Path” into “PATH” before. Probably something like ‘opam init’ although I could not find any proof it would do so just by inspecting the init scripts.
Rather than modifying opam in which ever way…of course.
@NAlec I added a series of patch to b0 that ended up with this one which should fix the odig issue you reported to me privately. Could you please try with: