bringing up the following issue here to see if Dune experts may be able to weigh in: https://github.com/coq/opam-coq-archive/issues/1995
File "nix/store/2w9yyr6c3py70kwsv8zvvx5afsfx3zx3-dune-2.8.5/bin/dune", line 1, characters 0-0: Error: Invalid dune file Cleaning up project directory and file based variables ERROR: Job failed: exit code 1
(This is not related to Dune for Coq though, but maybe some bad interaction between Nix and Dune)
can you run nix in a more verbose way to see what command it's running?
not sure, but you can see a failing job here which has some more hints: https://gitlab.com/coq/opam-coq-archive/-/jobs/1889653040
copying path '/nix/store/qdh5bjaz7xsd6imsl10f3nfcqylpyvxv-ocaml4.12.0-opam-core-2.0.8' from 'https://cache.nixos.org'... Info: Creating file dune-project with this contents: | (lang dune 2.8) File "nix/store/2w9yyr6c3py70kwsv8zvvx5afsfx3zx3-dune-2.8.5/bin/dune", line 1, characters 0-0: Error: Invalid dune file
The command that is executed is
nix-shell --run "dune exec --profile=release -- archive2web released extra-dev > coq-packages.json".
The error we see here happen within a successful
Thus it is the inner
dune exec --profile=release -- archive2web released extra-dev > coq-packages.json
And any change to verbosity of the Dune command should help.
yeah, it's from here: https://github.com/coq/opam-coq-archive/blob/c1a5336ebb0cfe0bbf3bab985f5157f1cf1a3fc0/.gitlab-ci.yml#L153-L163
The problem is that in this call, dune can't find the "root" for the project, thus it assumes the current dir is a root and creates the dune-proejct
for example this behavior has been reverted in 3.0
so dune exec is being called from the wrong directory
could it be due to this file being out of date: https://github.com/coq/opam-coq-archive/blob/master/dune-project
(lang dune 1.9) (name opam-coq-archive)
Not sure, the problem is that
dune exec is called from the wrong directory.
Yeah that's the problem
dune exec --profile=release -- archive2web released extra-dev
this is called from the root of the build, it should be something such as
cd $COQ_ARCHIVE_DIR && dune exec
or use the
how can this depend on the CI worker, or the OS version?
This problem depends on two things:
if your opam switch is in
_opam dune will not scan it
but here opam exec puts the cwd at the root of the switch build [weird, but it is this way]
pwd in that nix-shell call
and adjust using
As mentioned Dune 3.0 have slightly saner rules for when a workspace can be detected
but in this case the command would likely fail "cannot find dune workspace"
The problems reproducing this bug are IMHO due to a) the reproduction calls dune inside the right directory or b) the reproduction calls dune from the wrong directory, but the opam switch was not initialized yet so the
bin/dune clash is avoided, then dune will pick the workspace after scan
[which is a bit worrying and thus removed in 3.0]
This change had to wait for 3.0 as it is not backwards-compatible
this still does not explain why the bug pops up just now
Last updated: Jan 30 2023 at 18:04 UTC