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.
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? On Thu, May 7, 2015 at 12:53 AM, Louis Gesbert <[email protected]> wrote: > Hi all, > > At the moment, you have basically two solutions: > > - use a repository with `url` files pointing to version control ; this has > been covered already. The repo-per-package trick is quite interesting > though. > > This gives you all the flexibility of a full repository, but may be a > little bit of work to maintain. > > - 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>`. > > 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. > > In this scheme, one could put all pins as "uninstalled", and Thomas' > script would be replaced by: > ``` > opam switch import pinning-state > opam pin add -n project ./ -y # if not already in pinning-state > opam install --deps-only project -y > ``` > > 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. > > 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. > > If this sounds useful, but would be more convenient with more support > (e.g. export only pinning data ?) -- please ask (or contribute!) > > 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. > > 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. setup.ml) > > > `depends: [ "foo" { git: "path-to-git/foo#bar"} ]` > > `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 ? > > > > > - Ashish Agarwal, 05/05/2015 15:13 - > > > Has anyone else encountered this situation before? > > > > Yes, and I also would be interested in a good solution. One idea we had > was > > to share switch configurations. I'd like to say here's a whole switch: it > > has this name, these remotes (if remotes were switch specific), these > pins, > > etc. Then, I want to share this config with my team, and declare that a > > build machine should switch to this particular config. I have no idea how > > to do this though, other than hacking some shell script. > > > > > > On Tue, May 5, 2015 at 2:58 PM, Trevor Smith < > [email protected]> > > wrote: > > > > > Hi all, > > > > > > We're using opam internally at work. I have two use cases for our > internal > > > libraries: > > > > > > 1) "dev dependencies" -- I want what is in the repo. > > > 2) "explicit dependency" -- I want a given version. > > > > > > opam has #2 covered. > > > > > > However it is not clear to me how to do #1 correctly. I can, on a given > > > machine (ie not on an opam repository), pin a given package to a git > repo. > > > But locally pinning isn't what I want. I want a package in an opam > > > repository to say "I depend upon this other dev package" so that our > build > > > boxes, and various developer machines will all do the same thing, and I > > > don't need to separately pin everything on each box. > > > > > > Has anyone else encountered this situation before? > > > > > > Thoughts? Thanks. > > > > > > Trevor > > > > > > _______________________________________________ > > > Platform mailing list > > > [email protected] > > > http://lists.ocaml.org/listinfo/platform > > > > > > >
_______________________________________________ Platform mailing list [email protected] http://lists.ocaml.org/listinfo/platform
