Allows in-source metadata to sit in opam/, and other fixes #3194
Conversation
Closes ocaml#3173. Thanks for the remarks!
Closes ocaml#3185, thanks for the contribution!
since they have been so long we've been ignoring them for some time anyway
(in the same format) Closes ocaml#3159
| exported to the shell environment through `opam env` and | ||
| `~/.opam/opam-init/` scripts. | ||
| exported to the shell environment through `opam env` and `~/.opam/opam-init/` | ||
| scripts. Note that while it is guaranteed that dependents will see the |
There was a problem hiding this comment.
This is still a bit unclear to me. Specifically is opam env (+ user env at the moment) the environment in which builds happen on an opam install ? I.e. do all packages installed after the package that setenv:s see the environment update ?
There was a problem hiding this comment.
It's unspecified. Actually, currently, in practice, both can happen, depending on wether the package doing the setenv: is modified during the same run or not (if it's untouched, you'll see the setenv:, otherwise not). Basically, builds happen with opam env as if all the packages that are modified during the run were removed, + the setenv:s of their dependencies.
There was a problem hiding this comment.
It's unspecified.
I don't think this is a good idea. Especially since for now opam still mixes the user environment in an opam install people might get different builds whether they eval $(opam env)'d or not before doing an opam install. I think that given how opam works now (no user environment isolation) the only reasonable semantics is that the setenv of all installed packages is available in subsequent installs; that way the results will be the same whether the user eval'd or not in subsequent opam installs.
This also enables to have "environment packages" that allow to setup environment without other packages necessarily being aware of them (these things would typically be installed a switch creation time or could be mandated to be so).
There was a problem hiding this comment.
Basically, builds happen with
opam envas if all the packages that are modified during the run were removed, +the setenv:s of their dependencies.
This actually doesn't depend on wether opam env was evaluated in the meantime, it will remain true even if it hasn't
(modulo the imperfection of reverting env changes if it has, but it's a separate issue)
There was a problem hiding this comment.
I don't understand, opam install tries to fiddle with the user env beyond the addition of opam env ?
There was a problem hiding this comment.
More or less: opam install will internally revert the changes to the environment, then re-apply them according to the context.
This is very much what you want when running across switches:
eval $(opam env --switch foo)
opam install --switch bar somepkg
here we don't want the environment for the build of somepkg to be tainted by the setenv:s of unrelated switch foo. But this remains true even when in the same switch.
No description provided.