track opam file metadata in dune-project and rewrite opam files #2017

avsm · 2019-04-04T10:08:48Z

This adds support for recording some common metadata in the dune-project file that can be used for the purpose of generating packages descriptions. Initially, common metadata is stored in the toplevel dune-project that can be shared between package managers, and opam-specific metadata is stored within an opam field. This permits extension for direct support of other package managers in the future.

As a reward for putting this metadata in dune-project, dune can now rewrite opam files to keep the metadata recorded in dune-project in sync with all the project files. Updating the metadata in dune-project will result in opam.corrected files being written and normal dune promotion working. The current logic aims to leave opam files untouched for fields which are not specified in the dune-project file, and only rewrite ones which are specifically overridden there.

An example dune-project file with the metadata is here:

(lang dune 1.10)
(name cohttp)
(source (github mirage/ocaml-cohttp))
(license ISC)
(authors "Anil Madhavapeddy" "Rudi Grinberg")
(opam
  (tags org:mirage org:dune)
  (depends
   (ocaml (>= 4.06.0))
   (cohttp (>= 1.0.0))
  )
  (package
    (name cohttp)
    (synopsis "An OCaml library for HTTP clients and servers")
    (description "A longer description")
    (depends
      (alcotest :with-test)
      (dune (and :build (> 1.5)))
      (foo (and :dev (> 1.5) (< 2.0)))
      (uri (>= 1.9.0))
      (uri (< 2.0.0))
      (fieldslib (> v0.12))
      (fieldslib (< v0.13))))
  (package
    (name cohttp-async)
    (synopsis "HTTP client and server for the Async library")
    (description "A _really_ long description")
    (depends
      (cohttp (>= 1.0.2))
      (conduit-async (>= 1.0.3))
      (async (>= v0.10.0))
      (async (< v0.12))))
)

It may be useful to lift the a constraints field up to the toplevel for some packages such as ocaml, so that a future PR can use that metadata to generate CI test files automatically. We can extract that from the opam-specific metadata at present though, and defer that to a future PR.

(this branch is current a WIP, opening this to get more feedback on the approach while hacking with @jonludlam on it)

related to #1498

jberdine · 2019-04-04T10:15:39Z

Re feedback on the approach, I wonder if any thought has been given to the related problem of how to keep this metadata in sync with changes made to the opam files in the opam-repository? For example, it has happened that missing dependency version constraints were noticed and added directly to opam-repo, and then when I made a new release the added constraint was lost. Other than manually checking each package's opam file in the repo before each release, I don't know of a work flow to preserve such changes.

avsm · 2019-04-04T10:29:31Z

@jjb that's a really good question, and one I've also observed but not thought of a solution to yet. It's not quite clear to me whose responsibility (opam tooling vs dune tooling) it should be. One solution is to put it in the forthcoming duniverse/dune-get tool (https://github.com/avsm/duniverse) which acts as a bridge between both tools. Your usecase is now on my list as something that needs a solution.

jjb · 2019-04-04T11:17:46Z

@avsm i think you meant to tag @jberdine :) although this makes me dream of working with ocaml again…

avsm · 2019-04-04T12:58:13Z

Woops, I did indeed, sorry! Although if it subliminally encourages you to return to OCaml, then this PR has done its job well :-)

rauanmayemir · 2019-04-05T20:09:46Z

Could there be a way to indicate the libraries that a package provides as well? If dune project could set opam ‘constraints’ for a package, maybe there could be a soft way to have (libraries) set based on that information, too? It’s a bit circular: we’d want to know what libraries a package provides so that setting a constraint on that package could gather underlying libraries information. It’s not dune’s job to hold devs’ hand, but it sounds like a perfect job for some future dune-lsp tooling.

The common confusion for beginners is the package->library hierarchy and especially the naming quirks. ‘Admitting’ and protocoling the hierarchy could remove most of the friction.

rgrinberg · 2019-04-13T04:30:31Z

dune.opam

@@ -11,7 +11,6 @@ depends: [
  "base-threads"
 ]
 build: [
-  # opam 2 sets OPAM_SWITCH_PREFIX, so we don't need a hardcoded path


Why was this comment removed?

Hm was this removed due to the rewriting of the opam file removing comments. We should test that specifically to make sure comments are preserved

rgrinberg · 2019-04-13T05:54:37Z

@jonludlam I've cleaned up the PR and made the opam file diffing work when an extension is enabled in the dune-project file: (generate_opam_file).

One last thing that I'd like to see before the PR is merged is the removal of all pp/sexp functions introduced in favor of to_dyn functions.

rgrinberg · 2019-04-14T09:43:11Z

I've changed the status of this PR to be ready for review. One thing that I'd like a second opinion on is the name of this option in the dune-project file. Currently, it's (generate_opam_file), but perhaps it should be (lint_opam_file), or (correct_opam_file)?

rgrinberg · 2019-04-14T09:50:07Z

@jonludlam I got rid of blang_decode. I'm not sure why it was split this way, but it doesn't seem necessary anymore.

avsm · 2019-04-14T19:26:12Z

@rgrinberg wrote:

One thing that I'd like a second opinion on is the name of this option in the dune-project file. Currently, it's (generate_opam_file)

Why do we need this at all? Just the presence of the (opam clause in dune-project could activate this feature, and it could be explicitly disabled with a non-default option within that clause in the future. But if it causes problems, just removing the (opam clause should be sufficient.

rgrinberg · 2019-04-15T08:29:16Z

Yeah, I think that's acceptable as well. This would be a breaking change technically however. At least for people who have used this opam field before it did anything.

jonludlam · 2019-04-15T09:03:43Z

@rgrinberg Thanks very much! A few comments - I'm still leaning in the direction of executing this on runtest rather than install - mostly because I make test more often than I make install, and for this to be useful to duniverse it needs to be correct all the time. The blang_decode this was because at some point during development of this I got a circular dependency, but I'm very happy it's not necessary any more. The comments in the opam files are a bit annoying, but the current parser simply thows them away.

I've got some improvements to the docs generation that depends on this, but I'll make that in a separate PR when this is merged.

rgrinberg · 2019-04-15T09:33:00Z

mostly because I make test more often than I make install, and for this to be useful to duniverse it needs to be correct all the timee

Then I suppose there's no need to choose. We could make it a dependency of both aliases.

The comments in the opam files are a bit annoying, but the current parser simply thows them away.

Perhaps we should not do any correction if any comments are encountered? I don't think we can merge the code in its current state if it's going to drop user comments.

jonludlam · 2019-04-15T14:15:12Z

There is a 'format preserving printer' in v2.0.0 of opam-file-format which attempts to preserve comments - dune currently has 2.0.0~beta which predates it. Let me try upgrading that and seeing if we can use that to fix the opam comment issue.

jonludlam · 2019-04-15T14:45:55Z

That seems to do the trick. Just need to enable the rewriting on existence of (opam) now and hook it up to the runtest target as well as install.

avsm · 2019-04-15T15:47:37Z

@rauanmayemir I'm still thinking about your comment about merging libraries. It's fairly intertwined with opam's "special" status in dune as the unit of (package) definitions. I'll bring this up at the next dune developer meeting for a broader discussion to see how we can remove any duplication with this PR.

avsm · 2019-04-15T15:48:10Z

@jonludlam phew! That would have been quite the blocker for automated rewriting of opam files otherwise.

test/blackbox-tests/test-cases/dune-project-meta/proj

avsm · 2019-04-16T10:11:04Z

test/blackbox-tests/test-cases/dune-project-meta/proj

+      (>= uri 1.9.0)
+      (< uri 2.0.0)
+      (< fieldslib v0.12)
+      (< fieldslib v0.12)))


this is a duplicate - needs to be > something?

jonludlam · 2019-04-16T10:19:23Z

Just had a chat with @avsm - as it stands this PR does nothing with the constraints in dune-project, let's fix that so that the constraints are fixed in the opam files before we merge this.

rgrinberg · 2019-04-24T09:12:28Z

To make this feature more useful, we should consider adding the following checks:

dune can already discover the local package dependencies of a package, we could let the user know if such a package is missing from the list in the dune-project file.
Dune can consider all the library dependencies of all executables and libraries that belong to a library. It would then turn this into a package list and make sure that the user hasn't omitted any of the package dependencies inferred this way. Yes, this isn't perfect as findlib and opam package names do not match for some non-dune packages. As a workaround, we can add a way for the user to associate findlib to package names. This will not capture all dependencies either, nevertheless, it will be nice for the common case.

This last suggestion is a bit unrelated, but i've been meaning to bring it up before:

Currently, dune supports tests that don't belong to any package. That seems like a bit of a hidden pitfall to me because opam is executing the test suites per package. This results in the same tests being run multiple times. I'm wondering if we should warn users about such dangling tests, if this is desired, we can have them mark such tests explicitly: (package (dangling)).

avsm · 2019-04-24T10:05:04Z

All three of those suggestions seem like excellent ideas. I wonder if it's better to merge this PR and then do them separately, since they cover some semantic changes to dune files.

ghost · 2019-04-24T10:25:54Z

One second, where is the doc? :) We don't need to describe everything in detail, but the feature should at least be mentioned in the doc/ directory.

rgrinberg · 2019-04-24T12:16:38Z

I would like to squash all the commits as well, as the history isn't making much sense.

rgrinberg · 2019-04-24T12:34:44Z

I will add some brief docs and merge as this feature isn't complete yet.

@avsm we can merge this PR now, but I'd caution us against releasing features piecemeal. The issue is that it puts a versioning burden down the line. For example, if we add a depopts to dune-project, we would need to make it >= 1.11. That complicates things for the user and complicates our codebase with this versioning overhead, so it should be avoided if possible.

rgrinberg · 2019-04-24T13:30:14Z

I've jotted down some documentation in a new opam section. I think we need such a section because there's quite a few opam specific things we can document. The release workflow with dune-release is one glaring example of something that isn't so easy to lookup.

An alternative layout would be for this information to live in the dune project section instead, and the opam section can simply link to the appropriate dune-project section.

doc/opam.rst

ghost · 2019-04-24T14:49:45Z

Having a dedicated opam section in the manual seems good. Though, we should link it from the dune-project doc.

BTW, in the past, people have asked for a way to declare packages without writing <package>.opam files because they don't target opam. The natural answer would be to declare the list of packages in the dune-project file. However, if one doesn't target opam then it does feel right to write (opam (package ...)) to declare the list of packages. Instead, we could declare packages at the toplevel and write the opam specific fields inside it:

(lang dune 1.10)
(name foo)

(package
 (name foo)
 (opam <opam-specific-fields>))

(package
 (name bar)
 (opam <opam-specific-fields>))

Then someone who is not targetting opam would simply omit the opam fields. Sorry I only bring this up now, I didn't have the time to look at this PR before and only noticed this while looking at the documentation.

andreypopp · 2019-04-24T15:32:44Z

BTW, in the past, people have asked for a way to declare packages without writing .opam files because they don't target opam. The natural answer would be to declare the list of packages in the dune-project file.

I was about to comment on this. Thank you @diml for bringing this up.

It would be great to have a way to declare a package with dune without mentioning opam specifically as with esy we might not have an opam package in the first place (I think it might be confusing for novice esy users).

I'd also suggest not to include the cascading behaviour for depends and conflicts stanzas (an ability to specify those for all packages and for concrete pakcages). Not sure if it's worth it. I like that you can look at a a single package and see all its dependencies declared in a single place without the need to "merge" formulas. Maybe if boilerplate has become a problem in dune configs then it can be solved by some generic mechanism (named values)?

avsm · 2019-04-24T20:07:59Z

The (package) stanza makes sense to me. It would be really good to have a non-opam field there to ensure we haven't missed something. @andreypopp, would you have an example of what an esy file generated by these package stanzas might look like?

I also think the (package) field makes it possible to tighten up the slightly weird "dangling tests" semantics that @rgrinberg brought up earlier. We should ensure that everything is tied to exactly one package (so it isn't run multiple times), with a default package of the project name if there are no (package) stanzas.

rgrinberg · 2019-04-25T10:44:34Z

I'd also suggest not to include the cascading behaviour for depends and conflicts stanzas (an ability to specify those for all packages and for concrete pakcages). Not sure if it's worth it

@avsm what do you think? Having statically evaluated variables would indeed solve this problem and other similar ones. The depends boilerplate will be partially alleviated once dune is able to partially infer package deps.

avsm · 2019-04-25T12:45:10Z

I'm fine with the simpler non-cascading behaviour to start with, even if it's more verbose. There simply isn't that much overlap at the moment since we only have the opam backend.

avsm · 2019-04-25T12:47:33Z

Thanks for the squash commit @rgrinberg -- I think it also needs a Co-authored-by: Jon Ludlam <jon@recoil.org> as lots of the intermediate commits were his. This seems to be a cool new feature in GH: https://help.github.com/en/articles/creating-a-commit-with-multiple-authors

andreypopp · 2019-04-25T12:53:54Z

@avsm I don't think we want to generate esy metadata out of dune files, instead we can support dune-project files in esy directly.

I'm mainly interested in not having *.opam files at the root of projects managed with esy and then not having to specify opam metadata for non-opam packages (hence I'm asking for (package ...) stanza which is not specific to opam).

Ideally though with esy I'd like not to duplicate package name in multiple places (being it NAME.opam file or mentioning (package NAME) in dune-project) and Instead configuring dune with DUNE_PACKAGE_NAME or similar.

avsm · 2019-04-25T13:23:41Z

Sounds good. Do you have an example of a dune-managed package that doesn't have a corresponding opam package, anywhere? So far it seems that all dune packages do map to opam packages.

(I'm primarily aware that we don't have any non-opam tests at the moment, so some concrete example of using the non-opam package would be useful so we can ensure we do the right thing)

andreypopp · 2019-04-25T13:35:18Z

Do you have an example of a dune-managed package that doesn't have a corresponding opam package, anywhere? So far it seems that all dune packages do map to opam packages.

Yes! Having *.opam files is the requirement to use dune right now. This is why we are forced to create them even if they are completely empty — https://github.com/esy-ocaml/hello-reason/blob/master/hello-reason.opam. This is confusing for newcomers and I hope (package ...) stanza will make it less so. Though ideally, as I said, we don't have to duplicate package name in multiple places.

avsm · 2019-04-25T13:43:22Z

Got it -- so it's for the very important getting-started usecase, but nothing else more complex that we're missing. It will be nice to have a dune project description with just the dune-project and dune file to start with.

jonludlam · 2019-04-25T13:49:43Z

We could make it such that if you don't specify the package name it inherits the top-level name (and also ensure that no two packages have the same name)

(lang dune 1.10)
(name dune)

(package
  (opam
    (tags foo bar baz)))

Implicitly names that package 'dune'.

We could also change the check for a .opam file to additionally check for a (package) stanza in dune-project with the correct name - does that sound right?

rgrinberg · 2019-04-25T14:09:20Z

Thanks for the squash commit @rgrinberg -- I think it also needs a Co-authored-by: Jon Ludlam jon@recoil.org as lots of the intermediate commits were his. This seems to be a cool new feature in GH: help.github.com/en/articles/creating-a-commit-with-multiple-authors

Thanks, will do so.

We could make it such that if you don't specify the package name it inherits the top-level name (and also ensure that no two packages have the same name)

Seems good to me.

I will merge this PR as is, that should make it easier for all of us to contribute.

The agenda:

Allow dune to define packages purely in the dune-project file
Make the package stanza independent of opam
Remove shared conflicts/depends
Assume there's a single package named after the dune-project if there are no opam files.

@jonludlam Currently, the correction rules do no work if the opam file doesn't exist. I think dune should promote the opam file it assembled from the dune-project file.

We add metadata that can be used to used to partially specify opam files. Common fields such as depends, conflicts, authors, are all handled. Dune will now automatically suggest corrections to the existing opam files based on this metadata in the dune files Co-authored-by: Jon Ludlam <jon@recoil.org> Signed-off-by: Anil Madhavapeddy <anil@recoil.org> Signed-off-by: Rudi Grinberg <rudi.grinberg@gmail.com>

@aalekseyev

CHANGES: - Restricted the set of variables available for expansion in the destination filename of `install` stanza to simplify implementation and avoid dependency cycles. (ocaml/dune#2073, @aalekseyev, @diml) - [menhir] call menhir from context root build_dir (ocaml/dune#2067, @ejgallego, review by @diml, @rgrinberg) - [coq] Add `coq.pp` stanza to help with pre-processing of grammar files (ocaml/dune#2054, @ejgallego, review by @rgrinberg) - Add a new more generic form for the *promote* mode: `(promote (until-clean) (into <dir>))` (ocaml/dune#2068, @diml) - Allow to promote only a subset of the targets via `(promote (only <pred>))`. For instance: `(promote (only *.mli))` (ocaml/dune#2068, @diml) - Improve the behavior when a strict subset of the targets of a rule is already in the source tree for projects using the dune language < 1.10 (ocaml/dune#2068, fixes ocaml/dune#2061, @diml) - With lang dune >= 1.10, rules in standard mode are no longer allowed to produce targets that are present in the source tree. This has been a warning for long enough (ocaml/dune#2068, @diml) - Allow %{...} variables in pps flags (ocaml/dune#2076, @mlasson review by @diml and @aalekseyev). - Add a 'cookies' option to ppx_rewriter/deriver flags in library stanzas. This allow to specify cookie requests from variables expanded at each invocation of the preprocessor. (ocaml/dune#2106, @mlasson @diml) - Add more opam metadata and use it to generate `.opam` files. In particular, a `package` field has been added to specify package specific information. (ocaml/dune#2017, ocaml/dune#2091, @avsm, @jonludlam, @rgrinberg) - Clean up the special support for `findlib.dynload`. Before, Dune would simply match on the library name. Now, we only match on the findlib package name when the library doesn't come from Dune. Someone writing a library called `findlib.dynload` with Dune would have to add `(special_builtin_support findlib_dynload)` to trigger the special behavior. (ocaml/dune#2115, @diml) - Install the `future_syntax` preprocessor as `ocaml-syntax-shims.exe` (ocaml/dune#2125, @rgrinberg) - Hide full command on errors and warnings in development and show them in CI. (detected using the `CI` environment variable). Commands for which the invocation might be omitted must output an error prefixed with `File `. Add an `--always-show-command-line` option to disable this behavior and always show the full command. (ocaml/dune#2120, fixes ocaml/dune#1733, @rgrinberg) - In `dune-workspace` files, add the ability to choose the host context and to create duplicates of the default context with different settings. (ocaml/dune#2098, @TheLortex, review by @diml, @rgrinberg and @aalekseyev) - Add support for hg in `dune subst` (ocaml/dune#2135, @diml) - Don't build documentation for implementations of virtual libraries (ocaml/dune#2141, fixes ocaml/dune#2138, @jonludlam) - Fix generation of the `-pp` flag in .merlin (ocaml/dune#2142, @rgrinberg) - Make `dune subst` add a `(version ...)` field to the `dune-project` file (ocaml/dune#2148, @diml) - Add the `%{os_type}` variable, which is a short-hand for `%{ocaml-config:os_type}` (ocaml/dune#1764, @diml) - Allow `enabled_if` fields in `library` stanzas, restricted to the `%{os_type}`, `%{model}`, `%{architecture}`, `%{system}` variables (ocaml/dune#1764, ocaml/dune#2164 @diml, @rgrinberg) - Fix `chdir` on external and source paths. Dune will also fail gracefully if the external or source path does not exist (ocaml/dune#2165, fixes ocaml/dune#2158, @rgrinberg) - Support the `.cc` extension fro C++ sources (ocaml/dune#2195, fixes ocaml/dune#83, @rgrinberg) - Run `ocamlformat` relative to the context root. This improves the locations of errors. (ocaml/dune#2196, fixes ocaml/dune#1370, @rgrinberg) - Fix detection of `README`, `LICENSE`, `CHANGE`, and `HISTORY` files. These would be undetected whenever the project was nested in another workspace. (ocaml/dune#2194, @rgrinberg) - Fix generation of `.merlin` whenever there's more than one stanza with the same ppx preprocessing specification (ocaml/dune#2209 ,fixes ocaml/dune#2206, @rgrinberg) - Fix generation of `.meriln` in the presence of the `copy_files` stanza and preprocessing specifications of other stanazs. (ocaml/dune#2211, fixes ocaml/dune#2206, @rgrinberg)

@aalekseyev

CHANGES: - Restricted the set of variables available for expansion in the destination filename of `install` stanza to simplify implementation and avoid dependency cycles. (ocaml/dune#2073, @aalekseyev, @diml) - [menhir] call menhir from context root build_dir (ocaml/dune#2067, @ejgallego, review by @diml, @rgrinberg) - [coq] Add `coq.pp` stanza to help with pre-processing of grammar files (ocaml/dune#2054, @ejgallego, review by @rgrinberg) - Add a new more generic form for the *promote* mode: `(promote (until-clean) (into <dir>))` (ocaml/dune#2068, @diml) - Allow to promote only a subset of the targets via `(promote (only <pred>))`. For instance: `(promote (only *.mli))` (ocaml/dune#2068, @diml) - Improve the behavior when a strict subset of the targets of a rule is already in the source tree for projects using the dune language < 1.10 (ocaml/dune#2068, fixes ocaml/dune#2061, @diml) - With lang dune >= 1.10, rules in standard mode are no longer allowed to produce targets that are present in the source tree. This has been a warning for long enough (ocaml/dune#2068, @diml) - Allow %{...} variables in pps flags (ocaml/dune#2076, @mlasson review by @diml and @aalekseyev). - Add a 'cookies' option to ppx_rewriter/deriver flags in library stanzas. This allow to specify cookie requests from variables expanded at each invocation of the preprocessor. (ocaml/dune#2106, @mlasson @diml) - Add more opam metadata and use it to generate `.opam` files. In particular, a `package` field has been added to specify package specific information. (ocaml/dune#2017, ocaml/dune#2091, @avsm, @jonludlam, @rgrinberg) - Clean up the special support for `findlib.dynload`. Before, Dune would simply match on the library name. Now, we only match on the findlib package name when the library doesn't come from Dune. Someone writing a library called `findlib.dynload` with Dune would have to add `(special_builtin_support findlib_dynload)` to trigger the special behavior. (ocaml/dune#2115, @diml) - Install the `future_syntax` preprocessor as `ocaml-syntax-shims.exe` (ocaml/dune#2125, @rgrinberg) - Hide full command on errors and warnings in development and show them in CI. (detected using the `CI` environment variable). Commands for which the invocation might be omitted must output an error prefixed with `File `. Add an `--always-show-command-line` option to disable this behavior and always show the full command. (ocaml/dune#2120, fixes ocaml/dune#1733, @rgrinberg) - In `dune-workspace` files, add the ability to choose the host context and to create duplicates of the default context with different settings. (ocaml/dune#2098, @TheLortex, review by @diml, @rgrinberg and @aalekseyev) - Add support for hg in `dune subst` (ocaml/dune#2135, @diml) - Don't build documentation for implementations of virtual libraries (ocaml/dune#2141, fixes ocaml/dune#2138, @jonludlam) - Fix generation of the `-pp` flag in .merlin (ocaml/dune#2142, @rgrinberg) - Make `dune subst` add a `(version ...)` field to the `dune-project` file (ocaml/dune#2148, @diml) - Add the `%{os_type}` variable, which is a short-hand for `%{ocaml-config:os_type}` (ocaml/dune#1764, @diml) - Allow `enabled_if` fields in `library` stanzas, restricted to the `%{os_type}`, `%{model}`, `%{architecture}`, `%{system}` variables (ocaml/dune#1764, ocaml/dune#2164 @diml, @rgrinberg) - Fix `chdir` on external and source paths. Dune will also fail gracefully if the external or source path does not exist (ocaml/dune#2165, fixes ocaml/dune#2158, @rgrinberg) - Support the `.cc` extension fro C++ sources (ocaml/dune#2195, fixes ocaml/dune#83, @rgrinberg) - Run `ocamlformat` relative to the context root. This improves the locations of errors. (ocaml/dune#2196, fixes ocaml/dune#1370, @rgrinberg) - Fix detection of `README`, `LICENSE`, `CHANGE`, and `HISTORY` files. These would be undetected whenever the project was nested in another workspace. (ocaml/dune#2194, @rgrinberg) - Fix generation of `.merlin` whenever there's more than one stanza with the same ppx preprocessing specification (ocaml/dune#2209 ,fixes ocaml/dune#2206, @rgrinberg) - Fix generation of `.merlin` in the presence of the `copy_files` stanza and preprocessing specifications of other stanazs. (ocaml/dune#2211, fixes ocaml/dune#2206, @rgrinberg) - Run `refmt` from the context's root directory. This improves error messages in case of syntax errors. (ocaml/dune#2223, @rgrinberg) - In .merlin files, don't pass `-dump-ast` to the `future_syntax` preprocessor. Merlin doesn't seem to like it when binary AST is generated by a `-pp` preprocessor. (ocaml/dune#2236, @aalekseyev) - `dune install` will verify that all files mentioned in all .install files exist before trying to install anything. This prevents partial installation of packages (ocaml/dune#2230, @rgrinberg)

rgrinberg reviewed Apr 13, 2019

View reviewed changes

rgrinberg force-pushed the opam-file-rewriting branch 2 times, most recently from d9f721e to 73d314d Compare April 14, 2019 06:44

rgrinberg marked this pull request as ready for review April 14, 2019 09:41

rgrinberg requested a review from a user April 14, 2019 09:41

rgrinberg requested a review from emillon as a code owner April 14, 2019 09:41

rgrinberg force-pushed the opam-file-rewriting branch from 73d314d to 1578721 Compare April 14, 2019 09:49

rgrinberg closed this Apr 14, 2019

rgrinberg reopened this Apr 14, 2019

jonludlam force-pushed the opam-file-rewriting branch from 56d5d3b to 9ca9ed0 Compare April 15, 2019 14:44

jonludlam force-pushed the opam-file-rewriting branch from 9ca9ed0 to 44877ab Compare April 15, 2019 14:56

avsm commented Apr 15, 2019

View reviewed changes

test/blackbox-tests/test-cases/dune-project-meta/proj Outdated Show resolved Hide resolved

avsm commented Apr 16, 2019

View reviewed changes

rgrinberg force-pushed the opam-file-rewriting branch from 2ebeff3 to c65a332 Compare April 24, 2019 12:32

rgrinberg force-pushed the opam-file-rewriting branch from c65a332 to c48248a Compare April 24, 2019 13:27

ghost suggested changes Apr 24, 2019

View reviewed changes

doc/opam.rst Show resolved Hide resolved

rgrinberg force-pushed the opam-file-rewriting branch from c48248a to 5b54c8d Compare April 25, 2019 10:40

rgrinberg force-pushed the opam-file-rewriting branch from 5b54c8d to da5c978 Compare April 25, 2019 14:11

rgrinberg force-pushed the opam-file-rewriting branch from da5c978 to ca0f643 Compare April 27, 2019 10:50

rgrinberg merged commit 61387c5 into ocaml:master Apr 28, 2019

rgrinberg mentioned this pull request May 30, 2019

[new release] dune (1.10.0) ocaml/opam-repository#14215

Closed

rgrinberg mentioned this pull request Jun 4, 2019

[new release] dune (1.10.0) ocaml/opam-repository#14239

Merged

track opam file metadata in dune-project and rewrite opam files #2017

track opam file metadata in dune-project and rewrite opam files #2017

Conversation

avsm commented Apr 4, 2019 • edited Loading

jberdine commented Apr 4, 2019

avsm commented Apr 4, 2019

jjb commented Apr 4, 2019

avsm commented Apr 4, 2019

rauanmayemir commented Apr 5, 2019

rgrinberg Apr 13, 2019

Choose a reason for hiding this comment

avsm Apr 13, 2019

Choose a reason for hiding this comment

rgrinberg commented Apr 13, 2019

rgrinberg commented Apr 14, 2019

rgrinberg commented Apr 14, 2019

avsm commented Apr 14, 2019

rgrinberg commented Apr 15, 2019

jonludlam commented Apr 15, 2019

rgrinberg commented Apr 15, 2019

jonludlam commented Apr 15, 2019

jonludlam commented Apr 15, 2019

avsm commented Apr 15, 2019

avsm commented Apr 15, 2019

avsm Apr 16, 2019

Choose a reason for hiding this comment

jonludlam commented Apr 16, 2019

rgrinberg commented Apr 24, 2019

avsm commented Apr 24, 2019

ghost commented Apr 24, 2019 • edited by ghost Loading

rgrinberg commented Apr 24, 2019

rgrinberg commented Apr 24, 2019

rgrinberg commented Apr 24, 2019

ghost commented Apr 24, 2019

andreypopp commented Apr 24, 2019

avsm commented Apr 24, 2019

rgrinberg commented Apr 25, 2019

avsm commented Apr 25, 2019

avsm commented Apr 25, 2019

andreypopp commented Apr 25, 2019

avsm commented Apr 25, 2019

andreypopp commented Apr 25, 2019

avsm commented Apr 25, 2019

jonludlam commented Apr 25, 2019

rgrinberg commented Apr 25, 2019

avsm commented Apr 4, 2019 •

edited

Loading

ghost commented Apr 24, 2019 •

edited by ghost

Loading