<div dir="ltr">Louis,<div><br></div><div>Thanks for all of the info (and for making opam!)</div><div><br></div><div>1) I think that `opam update -u <my-internal-repo>` and then `opam upgrade` would indeed do what I need as a workaround. </div><div>The incidental complexity the it creates isn't that big of a deal for one-offs on my box, but when managing a team of devs, and build boxes one wants something straightforward.<br></div><div>It seems though that to make that work with the build system and to not have unintended updates one would then need 2 internal dev repos -- one that had all of the git versioned ones, and another repo that had your normal x.y.z versions.</div><div><br></div><div>2) I like my suggested solution better because I think it adds no incidental complexity -- one has to describe what needs describing (ie "I want this dependency always updated"), and no extra lifecycle commands (ie no explicit "update" after one has already pushed code). And adds a clear functionality to the tool.</div><div><br></div><div>Agreed that updating a ton of packages could take a while -- but having a clear tool (as in what I am suggesting) to define that gives the user that flexibility -- it's my fault if I've decided to have 100 "alpha" packages. I've asked for it.</div><div><br></div><div>So I'm clear -- are you saying that due to how updates are currently dealt with within opam that the feature I'm suggesting probably would not happen? (I haven't taken a look at how opam works).</div><div><br></div><div>Thanks.</div><div><br></div><div>Trevor</div></div><div class="gmail_extra"><br><div class="gmail_quote">On Sun, May 10, 2015 at 9:07 PM, Louis Gesbert <span dir="ltr"><<a href="mailto:louis.gesbert@ocamlpro.com" target="_blank">louis.gesbert@ocamlpro.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">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).<br>
<br>
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.<br>
<br>
Now for the dirty (and not really working) workarounds:<br>
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)<br>
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.<br>
<br>
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).<br>
<br>
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 ?<br>
<br>
Best,<br>
Louis<br>
<br>
> - Trevor Smith, 10/05/2015 19:55 -<br>
<div class="HOEnZb"><div class="h5">> Thanks Thomas.<br>
><br>
> Would there be interest in making a feature to "always update this<br>
> dependency"? Suggested solution:<br>
><br>
> A keyword in the version could trigger "always update". This would then<br>
> apply to both normal packages as well as pins. "Dev" already has meaning in<br>
> opam, perhaps "-alpha". This would then allow me to internally have a<br>
> single repo with normal versions alongside versions that are actively being<br>
> developed and changing multiple times per day. Eg:<br>
><br>
> my-repo/my-package.1.0-alpha/url:<br>
> src: "ssh://somewhere/my-package.git"<br>
><br>
> A dependent package (ie reverse dependency) "program" on: "my-package" {=<br>
> "1.0-alpha" } would then always check for updates and upgrade my-package<br>
> before doing anything with program. A build server could get the behavior<br>
> I'm looking for by "opam install --deps-only program" and getting whatever<br>
> is at head of my-package (or of the given branch as the case may be).<br>
><br>
> I think this solution would be a nice composition of the ideas that opam<br>
> already has, and, I think, would be a strict improvement over the current<br>
> situation and does not introduce any incidental complexity. This thread<br>
> seems to indicate that others are interested in such a feature.<br>
><br>
> Thoughts? Thanks!<br>
><br>
> Trevor<br>
><br>
><br>
><br>
> On Sun, May 10, 2015 at 5:50 PM, Thomas Gazagnaire <<a href="mailto:thomas@gazagnaire.org">thomas@gazagnaire.org</a>><br>
> wrote:<br>
><br>
> > Consider two packages: lib and program. program depends upon lib.<br>
> ><br>
> ><br>
> > opam install lib<br>
> > # Make a new commit to lib and push it<br>
> > # Lib is now one commit newer<br>
> > # NB I am making _no_ changes to the internal opam repo<br>
> > opam install program<br>
> ><br>
> > lib does _not_ get recompiled.<br>
> ><br>
> > Is that the information you wanted?<br>
> ><br>
> ><br>
> > yes, when pin/dev packages are modified, you need to tell opam that you<br>
> > want to use the updated version (if available), so you need to run `opam<br>
> > update -u` before `opam install program`. Opam will check if there are new<br>
> > commits and recompile what needs to be recompiled.<br>
> ><br>
> > Thomas<br>
> ><br>
> ><br>
> > Also: I just tried opam update program and that also did not pick up the<br>
> > fact that lib is git pinned.<br>
> ><br>
> > Thoughts? Thanks.<br>
> ><br>
> > Trevor<br>
> ><br>
> > On Sun, May 10, 2015 at 1:17 PM, Thomas Gazagnaire <<a href="mailto:thomas@gazagnaire.org">thomas@gazagnaire.org</a>><br>
> > wrote:<br>
> ><br>
> >> I tried setting up the "option 1" -- using a repo url. This works fine<br>
> >> for clean installs, however it does not work for my use case for updates. I<br>
> >> didn't realize until I tried it out that this won't update upon any<br>
> >> dependent installation. As noted by Louis, pinning also does not reinstall<br>
> >> from a repo url when a dependent install happens -- it only updates the<br>
> >> meta-data.<br>
> >><br>
> >> What I would like is a way (ideally within opam) to say "when this<br>
> >> package dependend-upon it should always be checked for update and upgrade".<br>
> >><br>
> >> Am I correct in stating that currently there is no way to mark a package<br>
> >> as "update and upgrade this package whenever something that depends upon it<br>
> >> is installed"?<br>
> >><br>
> >><br>
> >> did you run `opam update -u <package>`? If a or dev or pinned package<br>
> >> changes it should normally trigger a recompilation of all the reverse<br>
> >> dependencies. how did you specify the packages in your repo?<br>
> >><br>
> >> Thomas<br>
> >><br>
> >><br>
> >> Thanks.<br>
> >><br>
> >> Trevor<br>
> >><br>
> >> On Fri, May 8, 2015 at 2:24 PM, Daniel Bünzli <<br>
> >> <a href="mailto:daniel.buenzli@erratique.ch">daniel.buenzli@erratique.ch</a>> wrote:<br>
> >><br>
> >>> Le vendredi, 8 mai 2015 à 20:09, Ashish Agarwal a écrit :<br>
> >>> > Louis, thanks for your suggestions. I'm trying them out, but one quick<br>
> >>> question: how can you query with tags. I tried `opam list -e foobar`, and I<br>
> >>> seem to get the same output no matter what I write for foobar.<br>
> >>><br>
> >>> This is not opam tags this is depexts tags (that correspond to<br>
> >>> platform). You can do for example:<br>
> >>><br>
> >>>   opam search -s org:erratique<br>
> >>><br>
> >>> But it may not be entirely precise since opam-search matches not only in<br>
> >>> tags. I think opam-list should be able to filter by tags (I actually<br>
> >>> thought this was possible).<br>
> >>><br>
> >>> Best,<br>
> >>><br>
> >>> Daniel<br>
> >>><br>
> >>><br>
> >>> _______________________________________________<br>
> >>> Platform mailing list<br>
> >>> <a href="mailto:Platform@lists.ocaml.org">Platform@lists.ocaml.org</a><br>
> >>> <a href="http://lists.ocaml.org/listinfo/platform" target="_blank">http://lists.ocaml.org/listinfo/platform</a><br>
> >>><br>
> >><br>
> >> _______________________________________________<br>
> >> Platform mailing list<br>
> >> <a href="mailto:Platform@lists.ocaml.org">Platform@lists.ocaml.org</a><br>
> >> <a href="http://lists.ocaml.org/listinfo/platform" target="_blank">http://lists.ocaml.org/listinfo/platform</a><br>
> >><br>
> >><br>
> >><br>
> ><br>
> ></div></div></blockquote></div><br></div>