generate_opam_files seems broken in 2.0

[shonfeder]

I have not been able to generate opam files from dune files in 2.0. Here is a minimal example that works to generate an opam file with dune 1.11.4 but does not lead to a generated opam file for dune 2.0:

(lang dune 1.11)
(name foo)
(homepage https://my.home.page)

(generate_opam_files true)

(package
 (name foo)
 )

I'm guessing we also need tests to guard against this regression in the future.

[ghost]

I just gave this a try and it worked for me. How are you calling dune?

[shonfeder]

Oh! Maybe something to do with my environment then.. I am simply calling dune build in both cases...

I can try again on a fresh switch, and see if I can get some verbose output to help explain what's going on.

[shonfeder]

Argh.. frustrating. I can't reproduce on a fresh switch. I thought I'd tried that explicitly before opening this, but I must have had some state complicating things. If I figure out how to reproduce this, I'll reopen. In the meantime, sorry for the noise and thanks for your quick feedback.

[ghost]

No worries, this kind of things has happened to me as well in the past. One way to be sure it's reproducible is to add a test case to the dune test suite since these are quite well sandboxed. We use a custom version of cram tests so they are easy to write. Just add a directory with a run.t file in test/blackbox-tests/test-cases, run make test && make promote once to generate the dune boilerplate and then dune runtest (or dune @<name-of-the-test>) to run the test.

[shonfeder]

Thanks for the tip, @diml. I'll walk through this next time! In fact, do you think it would be helpful to supply guidance on creating these kinds of test cases in the issue submission template for this repo?

(If you think this would be useful, but don't have bandwidth to write it up, I'm happen to open a draft PR with an issue template summarizing your points here (and the info in HACKING.md).)

[ghost]

Yes! That would definitely be helpful. If issues could come with a reproduction case we could just merge, that would definitely make things easier.

A PR for this would be welcome :)

[kit-ty-kate]

I have a similar problem, dune build generates an opam file, but as soon as change to (lang dune 2.0) nothing gets updated anymore (removing the opam file doesn't help, changing the fields defined in the dune-project doesn't help either).

Also dune --version gives me:

$ dune --version
n/a

Reproduced with something like:

$ git clone https://github.com/ocaml-doc/octavius.git
$ cd octavius
$ # change something in the dune-project file
$ dune build
$ git diff
# an actual diff in the opam file
$ # change from (lang dune 1.11) to (lang dune 2.0)
$ change another field
$ git diff
# didn't change the opam file at all

Could this be reopened? Else I'll create a new issue.

[kit-ty-kate]

oh, I got it to work, but only if I call dune with -p <package>. Is this an expected change in dune 2.0?

[shonfeder]

Ahha! So I'm not crazy. Thanks for updating with with reproduction steps, @kit-ty-kate. I think this is also what I had done, updating from 1.11 to 2.0 on an existing project. I wonder if something is getting cached in the _build dir that's interfering with opam file generation? I don't think I tried a clean rebuild in between updates. (Currently, I've just pinned 1.11 to get WIP done, but may poke at this again this weekend if I get a chance.)

oh, I got it to work, but only if I call dune with -p . Is this an expected change in dune 2.0?

Before I opened this ticket I checked the changelog for some sign of breaking changes to opam file generation, and didn't find anything. Moreover, iirc, on a fresh project that starts off using dune 2.0, it seems the file generation is working as expected.

(I noticed the --version bug too, but saw there was a ticket open already, and I think it's been closed dy #2929.)

[ghost]

Alright, I understand what's happening:

• the default target when none is specified is @@default (alias "default", non-recursive), unless -p is given as it implies --default-target @install
• with (lang dune 1.x), unless explicitly defined alias "default" maps to alias "install"
• with (lang dune 2.x), unless explicitly defined alias "default" maps to alias "all"
• alias "install" depends on the opam files
• alias "all" doesn't depend on the opam files (this is the bug)

That explains the various behaviours observed. And indeed, if you do dune build octavius.opam or dune build @install, then the opam file does get updated.