…ne-site, dune-rpc, dune-rpc-lwt, dune-private-libs, dune-glob, dune-configurator, dune-build-info, dune-action-plugin and chrome-trace (3.6.0)

CHANGES:

- Forbid multiple instances of dune running concurrently in the same workspace.
  (ocaml/dune#6360, fixes ocaml/dune#236, @rgrinberg)

- Allow promoting into source directories specified by `subdir` (ocaml/dune#6404, fixes
  ocaml/dune#3502, @rgrinberg)

- Make dune describe workspace return the correct root path
  (ocaml/dune#6380, fixes ocaml/dune#6379, @esope)

- Introduce a `$ dune ocaml top-module` subcommand to load modules directly
  without sealing them behind the signature. (ocaml/dune#5940, @rgrinberg)

- [ctypes] do not mangle user written names in the ctypes stanza (ocaml/dune#6374, fixes
  ocaml/dune#5561, @rgrinberg)

- Support `CLICOLOR` and `CLICOLOR_FORCE` to enable/disable/force ANSI
  colors. (ocaml/dune#6340, fixes ocaml/dune#6323, @MisterDA).

- Forbid private libraries with `(package ..)` set from depending on private
  libraries that don't belong to a package (ocaml/dune#6385, fixes ocaml/dune#6153, @rgrinberg)

- Allow `Byte_complete` binaries to be installable (ocaml/dune#4873, @AltGr, @rgrinberg)

- Revive `$ dune external-lib-deps` under `$ dune describe external-lib-deps`.
  (ocaml/dune#6045, @moyodiallo)

- Fix running inline tests in bytecode mode (ocaml/dune#5622, fixes ocaml/dune#5515, @dariusf)

- [ctypes] always re-run `pkg-config` because we aren't tracking its external
  dependencies (ocaml/dune#6052, @rgrinberg)

- [ctypes] remove dependency on configurator in the generated rules (ocaml/dune#6052,
  @rgrinberg)

- Build progress status now shows number of failed jobs (ocaml/dune#6242, @Alizter)

- Allow absolute build directories to find public executables. For example,
  those specified with `(deps %{bin:...})` (ocaml/dune#6326, @anmonteiro)

- Create a fake socket file `_build/.rpc/dune` on windows to allow rpc clients
  to connect using the build directory. (ocaml/dune#6329, @rgrinberg)

- Prevent crash if absolute paths are used in the install stanza and in
  recursive globs. These cases now result in a user error. (ocaml/dune#6331, @gridbugs)

- Add `(glob_files <glob>)` and `(glob_files_rec <glob>)` terms to the `files`
  field of the `install` stanza (ocaml/dune#6250, closes ocaml/dune#6018, @gridbugs)

- Allow `:standard` in the `(modules)` field of the `coq.pp` stanza (ocaml/dune#6229,
  fixes ocaml/dune#2414, @Alizter)

- Fix passing of flags to dune coq top (ocaml/dune#6369, fixes ocaml/dune#6366, @Alizter)

- Extend the promotion CLI to a `dune promotion` group: `dune promote` is moved
  to `dune promotion apply` (the former still works) and the new `dune promotion
  diff` command can be used to just display the promotion without applying it.
  (ocaml/dune#6160, fixes ocaml/dune#5368, @emillon)

We want to enable the status line if and only if stderr is a tty. ANSI
color usage was tweaked in 3.6.0 with ocaml#6340 to allow users to force
colors. As status line activation actually depended on whether ANSI
colors were enabled or not, this change had the side effect to always
enable the status line even when ANSI colors were requested for
something that's not a tty.

Fix this by exposing a simple lazy wrapper of Unix.isatty to use
instead of Ansi_color.stderr_supports_color.

We want to enable the status line if and only if stderr is a tty. ANSI
color usage was tweaked in 3.6.0 with ocaml#6340 to allow users to force
colors. As status line activation actually depended on whether ANSI
colors were enabled or not, this change had the side effect to always
enable the status line even when ANSI colors were requested for
something that's not a tty.

Fix this by exposing a simple lazy wrapper of Unix.isatty to use
instead of Ansi_color.stderr_supports_color.

Signed-off-by: Antonin Décimo <antonin@tarides.com>

We want to enable the status line if and only if stderr is a tty. ANSI
color usage was tweaked in 3.6.0 with ocaml#6340 to allow users to force
colors. As status line activation actually depended on whether ANSI
colors were enabled or not, this change had the side effect to always
enable the status line even when ANSI colors were requested for
something that's not a tty.

Fix this by exposing a simple lazy wrapper of Unix.isatty to use
instead of Ansi_color.stderr_supports_color.

Signed-off-by: Antonin Décimo <antonin@tarides.com>

We want to enable the status line if and only if stderr is a tty. ANSI
color usage was tweaked in 3.6.0 with #6340 to allow users to force
colors. As status line activation actually depended on whether ANSI
colors were enabled or not, this change had the side effect to always
enable the status line even when ANSI colors were requested for
something that's not a tty.

Fix this by exposing a simple lazy wrapper of Unix.isatty to use
instead of Ansi_color.stderr_supports_color.

Signed-off-by: Antonin Décimo <antonin@tarides.com>

We want to enable the status line if and only if stderr is a tty. ANSI
color usage was tweaked in 3.6.0 with ocaml#6340 to allow users to force
colors. As status line activation actually depended on whether ANSI
colors were enabled or not, this change had the side effect to always
enable the status line even when ANSI colors were requested for
something that's not a tty.

Fix this by exposing a simple lazy wrapper of Unix.isatty to use
instead of Ansi_color.stderr_supports_color.

Signed-off-by: Antonin Décimo <antonin@tarides.com>

We want to enable the status line if and only if stderr is a tty. ANSI
color usage was tweaked in 3.6.0 with #6340 to allow users to force
colors. As status line activation actually depended on whether ANSI
colors were enabled or not, this change had the side effect to always
enable the status line even when ANSI colors were requested for
something that's not a tty.

Fix this by exposing a simple lazy wrapper of Unix.isatty to use
instead of Ansi_color.stderr_supports_color.

Signed-off-by: Antonin Décimo <antonin@tarides.com>

Signed-off-by: Antonin Décimo <antonin@tarides.com>
Co-authored-by: Antonin Décimo <antonin@tarides.com>

Since ocaml#6340 we're considering `CLICOLOR_FORCE` to determine whether
stderr supports color. However this changes behavior observable from the
test suite, so `CLICOLOR_FORCE=1 make test` fails (this is tracked as
ocaml#6607).

The issue is that ocaml/setup-ocaml#631, this variable is set in the CI
environment. So we disable it until the situation is fixed (and this
variable does not have observable changes anymore).

Signed-off-by: Etienne Millon <me@emillon.org>

Since ocaml#6340 we're considering `CLICOLOR_FORCE` to determine whether
stderr supports color. However this changes behavior observable from the
test suite, so `CLICOLOR_FORCE=1 make test` fails (this is tracked as
ocaml#6607).

The issue is that ocaml/setup-ocaml#631, this variable is set in the CI
environment. So we disable it until the situation is fixed (and this
variable does not have observable changes anymore).

Signed-off-by: Etienne Millon <me@emillon.org>

Since ocaml#6340 we're considering `CLICOLOR_FORCE` to determine whether
stderr supports color. However this changes behavior observable from the
test suite, so `CLICOLOR_FORCE=1 make test` fails (this is tracked as
ocaml#6607).

The issue is that ocaml/setup-ocaml#631, this variable is set in the CI
environment. So we disable it until the situation is fixed (and this
variable does not have observable changes anymore).

Signed-off-by: Etienne Millon <me@emillon.org>

Since ocaml#6340 we're considering `CLICOLOR_FORCE` to determine whether
stderr supports color. However this changes behavior observable from the
test suite, so `CLICOLOR_FORCE=1 make test` fails (this is tracked as
ocaml#6607).

The issue is that ocaml/setup-ocaml#631, this variable is set in the CI
environment. So we disable it until the situation is fixed (and this
variable does not have observable changes anymore).

Signed-off-by: Etienne Millon <me@emillon.org>

Since ocaml#6340 we're considering `CLICOLOR_FORCE` to determine whether
stderr supports color. However this changes behavior observable from the
test suite, so `CLICOLOR_FORCE=1 make test` fails (this is tracked as
ocaml#6607).

The issue is that ocaml/setup-ocaml#631, this variable is set in the CI
environment. So we disable it until the situation is fixed (and this
variable does not have observable changes anymore).

Signed-off-by: Etienne Millon <me@emillon.org>

* Set CLICOLOR_FORCE=0

Since #6340 we're considering `CLICOLOR_FORCE` to determine whether
stderr supports color. However this changes behavior observable from the
test suite, so `CLICOLOR_FORCE=1 make test` fails (this is tracked as
#6607).

The issue is that ocaml/setup-ocaml#631, this variable is set in the CI
environment. So we disable it until the situation is fixed (and this
variable does not have observable changes anymore).

Signed-off-by: Etienne Millon <me@emillon.org>

* Set CLICOLOR_FORCE=0

Since ocaml#6340 we're considering `CLICOLOR_FORCE` to determine whether
stderr supports color. However this changes behavior observable from the
test suite, so `CLICOLOR_FORCE=1 make test` fails (this is tracked as
ocaml#6607).

The issue is that ocaml/setup-ocaml#631, this variable is set in the CI
environment. So we disable it until the situation is fixed (and this
variable does not have observable changes anymore).

Signed-off-by: Etienne Millon <me@emillon.org>