Opam environment variable on windows

Is there a way to rename opam environment variables ?

in my opam environment, on my windows box, the “PATH” is named “Path” instead. Indeed, on Windows environment variables are case insensitive.

Although I renamed my variable from “Path” to “PATH”, opam still have “Path” instead of “PATH” (I closed all windows, reboot, etc…).

I thought it was because there is the System Path and the User Path, but renaming both of them doesn’t solve the issue.

Any hint ? Because some of the tools don’t work with “Path” instead of “PATH”

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?

That Path/PATH conflict has happened for me and others in my orbit too many times to count. I’ve mitigated it by reconstructing the PATH from scratch (ex. dkml-runtime-common/unix/crossplatform-functions.sh at b843693548c2c8e143a4057cf02ec9b640d52a87 · diskuv/dkml-runtime-common · GitHub) or with specialized hacks (ex. dkcoder/dk.cmd at 6f5cbdf3f6825eabb7e4552c0c8b2a50190f0dd2 · diskuv/dkcoder · GitHub) or (my preference) by rewriting shell scripts in something portable.

Also, in your own programs, you can add a bit of resilience by doing the case-insensitive folding in your own code anytime you access the environment. I did that myself last week in the MlFront_Core package: bugfix: Environment variables case-insensitive on Windows (041f2766) · Commits · DkML / Build Tools / MlFront · GitLab.

1 Like

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…

1 Like

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).

A fix is being prepared.

1 Like

Just how many decades are we talking? :grin:

C:>ver

Windows NT Version 4.0

C:\>set | findstr /b /i path=
Path=C:\WINNT\system32;C:\WINNT
1 Like

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:

C:\Devel>opam env | findstr /i path=
set "Path=..."

C:\Devel>set OP=%PATH%
C:\Devel>set PATH=
C:\Devel>set PATH=%OP%

C:\Devel>opam env | findstr /i path=
set "PATH=..."

C:\Devel>set PATH=

C:\Devel>C:\Users\...\opam.exe env | C:\Windows\System32\findstr /i path=
set PATH=...

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:

opam pin add cmdliner --dev-repo
opam pin add b0 --dev-repo
opam pin add odig --dev-repo

And tell me if that solved the issue.

Hello Daniel,

It looks like the odoc install failed.


PS H:\OCaml\stdlib-theme> opam pin add odig --dev-repo

[odig.0.0.9] synchronised (git+https://erratique.ch/repos/odig.git)

odig is now pinned to git+https://erratique.ch/repos/odig.git (version 0.0.9)

The following actions will be performed:

=== install 2 packages

∗ odig 0.0.9 (pinned)

∗ odoc 3.0.0 [required by odig]

Proceed with ∗ 2 installations? [y/n] y

<><> Processing actions <><><><><><><><><><><><><><><><><><><><><><><><><><> 🐫

⬇ retrieved odig.0.0.9 (no changes)

⬇ retrieved odoc.3.0.0 (cached)

[ERROR] The compilation of odoc.3.0.0 failed at "dune build -p odoc -j 3 @install".

#=== ERROR while compiling odoc.3.0.0 =========================================#

# context 2.2.1 | win32/x86_64 | | https://opam.ocaml.org#d4d1aa63ab7830b868cb8cbd85e076c699d8eb06

# path H:\OCaml\stdlib-theme\_opam\.opam-switch\build\odoc.3.0.0

# command H:\OCaml\stdlib-theme\_opam\bin\dune.exe build -p odoc -j 3 @install

# exit-code 1

# env-file ~\AppData\Local\opam\log\odoc-22416-fc18a4.env

# output-file ~\AppData\Local\opam\log\odoc-22416-fc18a4.out

### output ###

# (cd _build/default && H:\OCaml\stdlib-theme\_opam\bin\ocamlc.opt.exe -w -40 -g -w -18-53 -g -bin-annot -bin-annot-occurrences -I src/compat/.compatcmdliner.objs/byte -I H:\OCaml\stdlib-theme\_opam\lib\cmdliner -no-alias-deps -o src/compat/.compatcmdliner.objs/byte/compatcmdliner.cmo -c -impl src/compat/compatcmdliner.ml)

# File "src/compat/compatcmdliner.ml", line 15, characters 14-32:

# 15 | type info = Cmdliner.Term.info

# ^^^^^^^^^^^^^^^^^^

# Error: Unbound type constructor "Cmdliner.Term.info"

# (cd _build/default/src/html_support_files && H:\OCaml\stdlib-theme\_opam\bin\ocaml-crunch.exe . -e js -e css -e ttf -e woff2 -o odoc_html_support_files.ml -m plain)

# Generating odoc_html_support_files.ml

# Skipping generation of .mli

<><> Error report <><><><><><><><><><><><><><><><><><><><><><><><><><><><><> 🐫

┌─ The following actions failed

│ λ build odoc 3.0.0

└─

╶─ No changes have been performed

[NOTE] Pinning command successful, but your installed packages may be out of sync.

Ah yes you need to:

opam pin add odoc --dev-repo

The current release of odoc is incompatible with the upcoming cmdliner 2.0.0 and the dev version of b0 needs it.

3 posts were split to a new topic: Opam & git strategy for repos with symlinks on Windows