esy / esy/esy

Ability for released binaries to *not* augment findlib path.

Open
#25 0 comments 0 reactions 0 assignees View on GitHub
enhancement
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

Open the contributing 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

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.