<div dir="ltr">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.<div><br></div><div>Also, is there some convention for tags? You put "org:" as a prefix. Is there any special interpretation of this, now or planned in the future?</div><div><br></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Thu, May 7, 2015 at 12:53 AM, 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">Hi all,<br>
<br>
At the moment, you have basically two solutions:<br>
<br>
- use a repository with `url` files pointing to version control ; this has been covered already. The repo-per-package trick is quite interesting though.<br>
<br>
This gives you all the flexibility of a full repository, but may be a little bit of work to maintain.<br>
<br>
- use pinning. The bug-tracker mentionned `pin-bundles` to get a dev environment quickly at some point, and we actually quite have those already: you can import a set of pinnings through `opam switch import <file>`.<br>
<br>
The format is straight-forward: one line per package, with columns for name, version, "root"/"installed"/"uninstalled", pinning kind, pinning URL. You can generate the file with `opam switch export <file>` and remove unneeded lines, or write it by hand, then distribute it.<br>
<br>
In this scheme, one could put all pins as "uninstalled", and Thomas' script would be replaced by:<br>
```<br>
opam switch import pinning-state<br>
opam pin add -n project ./ -y # if not already in pinning-state<br>
<span class="">opam install --deps-only project -y<br>
```<br>
<br>
</span>This is less flexible, but is probably ligher-weight maintenance wise. A major difference is that `opam` files in all the pinned project's sources will be used.<br>
<br>
Then you have the difference in usage between normal repo and pinned packages. For example, any install command mentionning pinned package `foo` will first update it to get the latest metadata. This won't really handle depending on dev versions, but you may declare your packages' opam files with version "dev" and depend on this version in other packages: then installing with missing pins will fail, that version not being found. Another trick could be to use `available: [ foo:pinned ]` to make the package unavailable unless foo is pinned.<br>
<br>
If this sounds useful, but would be more convenient with more support (e.g. export only pinning data ?) -- please ask (or contribute!)<br>
<br>
Another pinning-related trick could be to mark all your packages with a given flag (e.g. "org:foobar") and then filter them and call `opam pin add --dev-repo` on all. Would need to go through some shell-script at the moment though.<br>
<br>
NOTE: there is something called "dev dependencies" planned (which is a dependency marked with the flag "dev", e.g. `depends: "foo" {dev & >= "1.2"}`), but it's different. It is planned to mean: ignore the dependency unless the package is pinned, and is to be used for processing artefacts that are usually in the tarball but not the git source (e.g. <a href="http://setup.ml" target="_blank">setup.ml</a>)<br>
<br>
> `depends: [ "foo" { git: "path-to-git/foo#bar"} ]`<br>
<br>
`depends` is basically information that is fed to the solver; we could interpret this, though, as "whenever this package is to be installed, make sure to pin 'foo' first". The issue with this is that pinning imports the package's metadata from its source -- and that metadata is needed by the solver. I don't see a way to handle this that's not too ad-hoc and wouldn't lead to a confusing interface: it would be easy in the case of explicitely installing the package that has this dependency, but otherwise ?<br>
<br>
<br>
<br>
> - Ashish Agarwal, 05/05/2015 15:13 -<br>
<div class="HOEnZb"><div class="h5">> > Has anyone else encountered this situation before?<br>
><br>
> Yes, and I also would be interested in a good solution. One idea we had was<br>
> to share switch configurations. I'd like to say here's a whole switch: it<br>
> has this name, these remotes (if remotes were switch specific), these pins,<br>
> etc. Then, I want to share this config with my team, and declare that a<br>
> build machine should switch to this particular config. I have no idea how<br>
> to do this though, other than hacking some shell script.<br>
><br>
><br>
> On Tue, May 5, 2015 at 2:58 PM, Trevor Smith <<a href="mailto:trevorsummerssmith@gmail.com">trevorsummerssmith@gmail.com</a>><br>
> wrote:<br>
><br>
> > Hi all,<br>
> ><br>
> > We're using opam internally at work. I have two use cases for our internal<br>
> > libraries:<br>
> ><br>
> > 1) "dev dependencies" -- I want what is in the repo.<br>
> > 2) "explicit dependency" -- I want a given version.<br>
> ><br>
> > opam has #2 covered.<br>
> ><br>
> > However it is not clear to me how to do #1 correctly. I can, on a given<br>
> > machine (ie not on an opam repository), pin a given package to a git repo.<br>
> > But locally pinning isn't what I want. I want a package in an opam<br>
> > repository to say "I depend upon this other dev package" so that our build<br>
> > boxes, and various developer machines will all do the same thing, and I<br>
> > don't need to separately pin everything on each box.<br>
> ><br>
> > Has anyone else encountered this situation before?<br>
> ><br>
> > Thoughts? Thanks.<br>
> ><br>
> > Trevor<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>
> ></div></div></blockquote></div><br></div>