usability bug: dune runtest -promote behaves in surprising/unexpected/annoying ways

[gasche]

I typed dune runtest -promote instead of dune promote in the bin/ subdirectory of a project with cram tests.

Expected Behavior

I would expect some error message suggesting that -promote is not a valid option.

Actual Behavior

Dune displays a weird message that I promptly ignored:

Info: Creating file dune-project with this contents:
| (lang dune 2.7)
File "dune", line 1, characters 0-118:
1 | (executable
2 |  (name mustache_cli)
3 |  (public_name mustache)
4 |  (modules mustache_cli)
5 |  (libraries mustache jsonm cmdliner))
Error: The current project defines some public elements, but no opam packages
are defined.
Please add a <package>.opam file at the project root so that these elements
are installed into it.

At this point, further attempts to run dune runtest fail:

Entering directory '/home/gasche/Prog/blog/mustache'
File "bin/dune", line 1, characters 0-118:
1 | (executable
2 |  (name mustache_cli)
3 |  (public_name mustache)
4 |  (modules mustache_cli)
5 |  (libraries mustache jsonm cmdliner))
Error: The current project defines some public elements, but no opam packages
are defined.
Please add a <package>.opam file at the project root so that these elements
are installed into it.

the reason is that a dune-project file was created in the bin/ subdirectory, which is wrong. (Note: the first message said so exactly, but then who reads error messages? I took me a couple minutes to figure out what the issue was.) Removing the spurious dune-project file fixes the issue, and dune can be used again.

I suspect that the problematic behavior comes from an interaction with the -p <packages> option. Parsing -promote as -p romote is not-useful (but then maybe it's important for consistency with other single-letter options?), but doing weird stuff when trying to build a package that does not exist, effectively getting the user repository in a broken state, is probably the core issue. (I don't know when this behavior is useful, but maybe it's not possible to keep the useful behavior without also allowing this annoying behavior, in which case feel free to say so and close the issue.)

Note

dune runtest --promote does not have such a negative side-effect, but the --promote option appears to be silently ignored and dropped.

Specifications

• Version of dune: v2.7.1

Additional information

• Link to gist with verbose output (run dune with the --verbose flag):

[ghost]

Regarding not parsing -promote as -p romote, that's more a discussion for cmdliner.

Regarding not creating the dune-project file in this case, that seems reasonable. Creating the dune-project file automatically is meant for development, while -p is meant for release builds. So -p could definitely imply "don't create or edit dune files in the source tree".

[gasche]

Thanks for the prompt feedback. When are dune-project files created, and what is the intention? I would expect this to be a reasonable action to setup a new repository, but I wouldn't expect it to happen during runtest for example.

[ghost]

The intent is that Dune "remembers" what version of Dune you are using to work on some code. This way, when you come back to it later with a new version of Dune, things still work the same.

Dune can work outside of a project, so the project creating step is not mandatory. That's why Dune doesn't rely on it. dune init also didn't exist at the beginning.

[ghost]

I introduced the idea of Dune creating and editing the dune-project file a while ago, at a time where there was less discussions on new features.

We discussed this feature today at the Dune meeting and unanimously agreed it was a bad idea, so we will remove it in Dune 3.0.0.

[ghost]

I created an issue to remember to do it: #4108

[gasche]

Is this issue still relevant? I think that the dune-project behavior changed recently.

[Alizter]

dune-project is no longer created automatically. However the literal above issue instead gives:

  $ dune runtest -promote
  Error: I don't know about package romote (passed through --only-packages)
  [1]

Here it was interpreted as

  $ dune runtest -p romote

which is really about the -p argument. It doesn't cause weird errors like before, but the cmdliner arguments are a bit flexible with how you can pass arguments to short form flags.

On the other hand,

  $ dune runtest --promote

works fine. I think before the -p flag tricked dune into creating a project at the working directory and caused the build to fail later on.

Therefore I think this issue has been resolved by the removal of the autocreation of dune-project.