ocaml / ocaml/dune

Thoughts about management of the environment

Open
#4,382 1 comment 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

build engine
Dominant language
OCaml
Stars
1.9k
Forks
500
Avg merge
15h 21m
Merged PRs (30d)
277

Description

Dumping here the result of various discussions we had with about environment variables, for future reference.

Currently, Dune passes through the environment it is executed in to commands it runs. The only management of the environment we do is allowing users to declare dependency on environment variables, so that actions are re-executed when such environment variables change.

There are several issues we know about regarding the environment:

  • we don't have a good way of detecting when an action depends on an environment variable without declaring it. When this happens, we will sometimes not re-execute an action when we should instead do it
  • Dune sets various environment variable to local paths, for instance it sets PATH so that commands can access binaries with a public name or binaries locally added to the PATH via (env (_ (binaries ...))). It does something similar for libraries by setting OCAMLPATH. When an aciton is sandboxed, such variables still point to paths outside of the sandbox, allowing actions to "escape" the sandbox and see things they are not supposed to see

For the first issue, we discussed and/or tested a few ideas:

  • making Dune very strict, by cleaning the environment and only passing variables declared as dependencies. This might be tedious to actionate, as for instance the libc or some other library might be reading some variable to be set that we don't know about
  • taking into account the whole environment when memoizing command. That would mean that changing a single variable would cause Dune to re-execute all actions, which is probably too extreme
  • doing something in the middle: being strict about variables Dune knows about. For instance, if the user sets X via the env stanza, then any action declaring a dependency on X will see it, and X will be clearer from the environment of actions that don't declare a dependency on it

As always, any behaviour change should be tied to the version of the Dune language to ensure good backward compatibility.

We are currently passing around the environment as a string map, and overall it feels like we should probably use some more structured representation.

Contributor guide

Open the contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

Research direction

The issue names no files, tests, or entry points; begin by locating Dune's environment representation, memoization logic, and sandbox handling. Compare the discussed environment-management options and language-version compatibility requirements, then define the intended behavior before implementation.

Written by the indexing model from the issue text.

Assessment

Tech stack
ocaml
Domain
build-system
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.