<div dir="ltr">Well, this single repository needs to be added once per project. And it contains some redundant information with respect to your main repository. For instance, you might be tempted to duplicate the descr file and some part of the opam file. With the url in opam file scheme, you wouldn't need to duplicate this, since you would be able to get all the relevant information in the opam file of the target package.<div><br></div><div> </div></div><div class="gmail_extra"><br><div class="gmail_quote">On Wed, May 6, 2015 at 3:22 PM, Trevor Smith <span dir="ltr"><<a href="mailto:trevorsummerssmith@gmail.com" target="_blank">trevorsummerssmith@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">@Thomas Braibant -- why is having to depend on this other repository a pain? It's not clear to me. Can you explain more? It seems to me there would only be a single repository to add, one time. But I am probably missing something.<div><br></div><div>Thanks.</div><span class="HOEnZb"><font color="#888888"><div><br></div><div>Trevor</div></font></span></div><div class="HOEnZb"><div class="h5"><div class="gmail_extra"><br><div class="gmail_quote">On Wed, May 6, 2015 at 4:51 AM, Thomas Braibant <span dir="ltr"><<a href="mailto:thomas.braibant@gmail.com" target="_blank">thomas.braibant@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">Hi,<div><br><div class="gmail_extra"><div class="gmail_quote"><span><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir="ltr"><div>I'm going to try to have an internal opam repo with {package-name}.dev for all internal libraries. This dev version will reference a git repo in the url file. Dependent projects will reference dev as we are building. When we make a release we'll do the normal thing and create a version. This strategy should scale well -- if one has multiple concurrent long-lived versions one can use version "-dev" (again as in Maven SNAPSHOTS). If this ends up serving us well I'll shoot out a blog post about it as it seems there is a lot of interest and different solutions around this topic.</div><div><br></div></div></blockquote><div><br></div></span><div>Well, we choose to host this internal opam repository in the source code of our main project, which helps scaling down the issue of having multiple concurrent long lived versions of dev packages. That way, we keep all the data relevant to how we built the project in one single place (we do not have to cross reference the contents of a shared opam-repository with the state of the project we built when we try to investigate something). </div><div><br></div><div>That being said, having to depend on such a repository is a pain. What we would really to do from a user perspective is to have something like that in the project opam file </div><div><div><br></div><div>```</div><div>opam-version: "1.2"</div></div><div>...</div><div><div>depends: [</div><div>  "asn1-combinators" { = "0.1.1" }<br></div></div><div><div>  ...</div><div>  "foo" { git: "path-to-git/foo#bar"}</div></div><div>]</div><div>```</div><div><br></div><div>If the foo repository contains an opam file, this would work almost as well as dev-repos, except that's something that can be configured by the user of the package rather than by the developer of the package. </div><div><br></div><div>Thoughts?</div></div></div></div></div>
</blockquote></div><br></div>
</div></div></blockquote></div><br></div>