setup-ocaml
setup-ocaml copied to clipboard
Option to add binaries to path
It would be nice if I could set some variable to true
to have the opam environment added to path, so I don't need to opam exec
everything. (It might be the case that running opam env >> $GITHUB_ENV
is enough?)
Actually, I think you need opam env | sed "s/'//g; s/; export .*//g" >> $GITHUB_ENV
It's better to use opam exec
(because it's explicit), but I agree that this would be a useful feature
I agree with @dra27, opam exec
is better. We can get rid of this by passing --enable-shell-hook
to opam init
, but still the behavior is often unstable.
--enable-shell-hook
won't work for the Windows shells (yet) - it only works for bash, etc.
I think @JasonGross posted the answer in his followup comment
opam env | sed "s/'//g; s/; export .*//g" >> $GITHUB_ENV
Modifying GITHUB_ENV is sufficient for future steps in the workflow to inherit the env, and it would simplify subsequent commands. It might be best to make this a non-default option in the workflow config though, in case it has unexpected consequences (such as an opam switch in a future step nullifying it).
Of course I can add something to the action that handles this well, but I also think it would be smarter to add a better fix to opam after this summer.
I just opened a PR to address this. Since v2 removed quite a lot of the differences between each platform, it was done in a fairly simple way.
having opam environment set up would allow to not duplicate build commands in yml, but invoke same wrapper as developers are using (e.g. make)
I feel that this is a more opam issue that needs to be fixed, but can it be fixed on the opam side? I actually use opam exec a lot locally as well as on CI, which is a bit odd.
~Since the exact version of opam is available on all platforms, opam exec
will no longer be needed by default in the next release! (in other words, v3!)
See #794~