[ocaml-platform] Dev Version as Package?

[Louis Gesbert]

OPAM normally never updates its metadata outside of `opam update`; this was inconvenient for pins, so a trick was added: when a pinned package is mentionned explicitely on an install command-line, it is first updated from its upstream. Updating all the time could get very slow if you have many packages pinned to their upstream, for example (like I do).

As for reinstallations, OPAM does the minimum reinstallations to guarantee consistency, i.e. it recompiles only packages that depend on a changed one -- not the other way around. It will, however, mark packages that were changed after an update for reinstallation. This should work in a similar way for repository and pinned packages. However, that reinstallation will only take place on an `opam upgrade` without argument; it would probably be an improvement to process it as soon as it belongs to the dependency cone of changed packages.

Now for the dirty (and not really working) workarounds:
1. `alias opam="opam update --dev; opam"`. (this would work with the fix above; and the option --dev doesn't exist at the moment, we only have an option --repositories. Adding it)
2. Instead of `opam install foo`, fun `opam install $(opam list -s --rec --required-by foo) foo`. This should trigger updates due to the trick above. The reinstallations are only done on `opam upgrade` though.

So indeed, your only real option if you want to keep your stuff up-to-date is to run `opam update -u` beforehand (possibly with your dev-repo name, or --dev, depending on whether you use a custom repo or pinned packages).

Now, if we were to handle planned recompilations more often than only on global `opam upgrade`, would that be enough to handle your use-case better ?

Best,
Louis

> - Trevor Smith, 10/05/2015 19:55 -
> Thanks Thomas.
> 
> Would there be interest in making a feature to "always update this
> dependency"? Suggested solution:
> 
> A keyword in the version could trigger "always update". This would then
> apply to both normal packages as well as pins. "Dev" already has meaning in
> opam, perhaps "-alpha". This would then allow me to internally have a
> single repo with normal versions alongside versions that are actively being
> developed and changing multiple times per day. Eg:
> 
> my-repo/my-package.1.0-alpha/url:
> src: "ssh://somewhere/my-package.git"
> 
> A dependent package (ie reverse dependency) "program" on: "my-package" {=
> "1.0-alpha" } would then always check for updates and upgrade my-package
> before doing anything with program. A build server could get the behavior
> I'm looking for by "opam install --deps-only program" and getting whatever
> is at head of my-package (or of the given branch as the case may be).
> 
> I think this solution would be a nice composition of the ideas that opam
> already has, and, I think, would be a strict improvement over the current
> situation and does not introduce any incidental complexity. This thread
> seems to indicate that others are interested in such a feature.
> 
> Thoughts? Thanks!
> 
> Trevor
> 
> 
> 
> On Sun, May 10, 2015 at 5:50 PM, Thomas Gazagnaire <thomas at gazagnaire.org>
> wrote:
> 
> > Consider two packages: lib and program. program depends upon lib.
> >
> >
> > opam install lib
> > # Make a new commit to lib and push it
> > # Lib is now one commit newer
> > # NB I am making _no_ changes to the internal opam repo
> > opam install program
> >
> > lib does _not_ get recompiled.
> >
> > Is that the information you wanted?
> >
> >
> > yes, when pin/dev packages are modified, you need to tell opam that you
> > want to use the updated version (if available), so you need to run `opam
> > update -u` before `opam install program`. Opam will check if there are new
> > commits and recompile what needs to be recompiled.
> >
> > Thomas
> >
> >
> > Also: I just tried opam update program and that also did not pick up the
> > fact that lib is git pinned.
> >
> > Thoughts? Thanks.
> >
> > Trevor
> >
> > On Sun, May 10, 2015 at 1:17 PM, Thomas Gazagnaire <thomas at gazagnaire.org>
> > wrote:
> >
> >> I tried setting up the "option 1" -- using a repo url. This works fine
> >> for clean installs, however it does not work for my use case for updates. I
> >> didn't realize until I tried it out that this won't update upon any
> >> dependent installation. As noted by Louis, pinning also does not reinstall
> >> from a repo url when a dependent install happens -- it only updates the
> >> meta-data.
> >>
> >> What I would like is a way (ideally within opam) to say "when this
> >> package dependend-upon it should always be checked for update and upgrade".
> >>
> >> Am I correct in stating that currently there is no way to mark a package
> >> as "update and upgrade this package whenever something that depends upon it
> >> is installed"?
> >>
> >>
> >> did you run `opam update -u <package>`? If a or dev or pinned package
> >> changes it should normally trigger a recompilation of all the reverse
> >> dependencies. how did you specify the packages in your repo?
> >>
> >> Thomas
> >>
> >>
> >> Thanks.
> >>
> >> Trevor
> >>
> >> On Fri, May 8, 2015 at 2:24 PM, Daniel Bünzli <
> >> daniel.buenzli at erratique.ch> wrote:
> >>
> >>> Le vendredi, 8 mai 2015 à 20:09, Ashish Agarwal a écrit :
> >>> > Louis, thanks for your suggestions. I'm trying them out, but one quick
> >>> question: how can you query with tags. I tried `opam list -e foobar`, and I
> >>> seem to get the same output no matter what I write for foobar.
> >>>
> >>> This is not opam tags this is depexts tags (that correspond to
> >>> platform). You can do for example:
> >>>
> >>>   opam search -s org:erratique
> >>>
> >>> But it may not be entirely precise since opam-search matches not only in
> >>> tags. I think opam-list should be able to filter by tags (I actually
> >>> thought this was possible).
> >>>
> >>> Best,
> >>>
> >>> Daniel
> >>>
> >>>
> >>> _______________________________________________
> >>> Platform mailing list
> >>> Platform at lists.ocaml.org
> >>> http://lists.ocaml.org/listinfo/platform
> >>>
> >>
> >> _______________________________________________
> >> Platform mailing list
> >> Platform at lists.ocaml.org
> >> http://lists.ocaml.org/listinfo/platform
> >>
> >>
> >>
> >
> >
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 473 bytes
Desc: This is a digitally signed message part.
URL: <http://lists.ocaml.org/pipermail/platform/attachments/20150511/2e3830f5/attachment.sig>