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 nix-shell
AFAICT.
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 --root
option
how can this depend on the CI worker, or the OS version?
This problem depends on two things:
bin/dune
is foundif 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]
so check pwd
in that nix-shell call
and adjust using --root
or cd
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: Oct 13 2024 at 01:02 UTC