Nested dune call fix (executable resolution part) #12902
Conversation
Why is it independent? I think if you were to insert dune in the PATH correctly, it would be enough to respect this PATH when doing binary look ups. I think it would make this work redundant. |
Inserting dune in
To further address the issues in 2 we need to probably create a temporary home for The technical details of the temporary directory need to be correctly sorted out. i.e. where does it live? Should be on the same file system, should be hardlinked etc. |
Leonidas-from-XIV
force-pushed
the
nested-dune-call-part-i
branch
from
f06d1d1 to
136f99b
Compare
|
Discussing this with @Alizter we noticed that we need a way to call a specific dune (the dune under test) but in a way where It turns out our initial solution |
|
We still need to check that this does something sane on the platforms we are interested in, but if it turns out not to be the case, I think introducing our own way of determining this is better. Generally relying on |
The way the test is implemented, the code testing dune is always calling the (outside, Dune unter test) via its absolute path. This change, extracted from ocaml#12902 calls Dune via absolute path but wraps it in an untility where argv[0] is set to "dune" instead of the absolute path, more closely resembling a call to `dune build` instead of (a hypothetical) `/usr/bin/dune build`. Signed-off-by: Marek Kubica <[email protected]>
The way the test is implemented, the code testing dune is always calling the (outside, Dune unter test) via its absolute path. This change, extracted from ocaml#12902 calls Dune via absolute path but wraps it in an utility where argv[0] is set to "dune" instead of the absolute path, more closely resembling a call to `dune build` instead of (a hypothetical) `/usr/bin/dune build`. Signed-off-by: Marek Kubica <[email protected]>
The way the test is implemented, the code testing dune is always calling the (outside, Dune unter test) via its absolute path. This change, extracted from ocaml#12902 calls Dune via absolute path but wraps it in an utility where argv[0] is set to "dune" instead of the absolute path, more closely resembling a call to `dune build` instead of (a hypothetical) `/usr/bin/dune build`. Signed-off-by: Marek Kubica <[email protected]>
The way the test is implemented, the code testing dune is always calling the (outside, Dune unter test) via its absolute path. This change, extracted from ocaml#12902 calls Dune via absolute path but wraps it in an utility where argv[0] is set to "dune" instead of the absolute path, more closely resembling a call to `dune build` instead of (a hypothetical) `/usr/bin/dune build`. Signed-off-by: Marek Kubica <[email protected]>
The way the test is implemented, the code testing dune is always calling the (outside, Dune unter test) via its absolute path. This change, extracted from ocaml#12902 calls Dune via absolute path but wraps it in an utility where argv[0] is set to "dune" instead of the absolute path, more closely resembling a call to `dune build` instead of (a hypothetical) `/usr/bin/dune build`. Signed-off-by: Marek Kubica <[email protected]>
The way the test is implemented, the code testing dune is always calling the (outside, Dune unter test) via its absolute path. This change, extracted from ocaml#12902 calls Dune via absolute path but wraps it in an utility where argv[0] is set to "dune" instead of the absolute path, more closely resembling a call to `dune build` instead of (a hypothetical) `/usr/bin/dune build`. Signed-off-by: Marek Kubica <[email protected]>
The way the test is implemented, the code testing dune is always calling the (outside, Dune unter test) via its absolute path. This change, extracted from ocaml#12902 calls Dune via absolute path but wraps it in an utility where argv[0] is set to "dune" instead of the absolute path, more closely resembling a call to `dune build` instead of (a hypothetical) `/usr/bin/dune build`. Signed-off-by: Marek Kubica <[email protected]>
…12916) The way the test is implemented, the code testing dune is always calling the (outside, Dune unter test) via its absolute path. This change, extracted from #12902 calls Dune via absolute path but wraps it in an utility where argv[0] is set to "dune" instead of the absolute path, more closely resembling a call to `dune build` instead of (a hypothetical) `/usr/bin/dune build`.
Signed-off-by: Marek Kubica <[email protected]>
Signed-off-by: Marek Kubica <[email protected]>
Leonidas-from-XIV
force-pushed
the
nested-dune-call-part-i
branch
from
136f99b to
2ab67c1
Compare
| $ PATH=$fakepath $DUNE build "$pkg_root/$bar_digest/target/" | ||
| Fake dune! (args: build -p bar @install) | ||
|
|
||
| Make sure that fake dune is not picked up when dune is called with argv[0] = "dune": |
There was a problem hiding this comment.
For others reading, Sys.executable_name uses a heuristic to determine the executable name. The fallback in all cases is argv[0]. On Linux we are inspecting /proc/, however I am unsure what happens on macOS or Windows.
3 participants
#10019 mentions that Dune should run itself when encountering package rules, which is quite sensible to do. This PR fixes part of the problem - the
runcommand resolution. When encountering a command dune attempts to look up the programs path. But if the command isdune, we can immediately resolve this to the current executable (was we are Dune, even if the command is not calleddunebutdune.exeormain.exeor something else). This prevents capture of an accidental dune executable (as exhibited by the repro fix).This PR thus solves the first case of #10020, where
duneis called directly. It does not fix the second part (dune not part of the path), which requires a different fix that I intend to submit as a separate PR (as the fix is somewhat independent from this one).