Ability for released binaries to *not* augment findlib path.
- Dominant language
- Reason
- Stars
- 857
- Forks
- 95
- PR merge metrics
- No merged PRs in 30d
Description
We still want to export a wrapper script that `exec`s the correct version of the binary, but without augmenting things like `OCAMLPATH` - or really any part of the environment.
Here's a couple of examples where it's important:
```
# The local project's `esy` environment is overwritten by the `esyvim`
# binary wrapper's environment.
esy esyvim myFile.re
# If vim is using the globally installed `ocamlmerlin` that has a wrapper
# then the local project's `esy` environment will be overwritten by
# the global `ocamlmerlin`'s. This forces you to install merlin as a dev
# dependency which is also a good approach, but it would be nice if
# you didn't have to.
esy vim myFile.re
```
This can really only be decided on a per application basis. Packages that are released must decide if it makes sense for their use case to wrap the binaries.
I'd say that `esyvim` would opt out of wrapping, and so would `ocamlmerlin`.
The other approach is to let released binaries decide if they want to wrap, but only if not already running in an environment.
Contributor guide
Research direction
Start at the released-binary wrapper that execs the selected version and trace where OCAMLPATH and other environment changes are applied. Compare the proposed per-application opt-out with wrapping only outside an existing environment. Done means the policy is defined for esyvim and ocamlmerlin and its behavior is covered by tests.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- ocaml
- Domain
- tooling
- Issue type
- Feature
- Difficulty
- 5/5
- Estimated time
- Over a week
- Activity status
- Stale
- Clarity
- Needs clarification
- Newbie friendliness
- 25/100