[ocaml-platform] Dev Version as Package?

[Ashish Agarwal]

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 <louis.gesbert at ocamlpro.com>
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 <
> trevorsummerssmith at gmail.com>
> > 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
> > > Platform at lists.ocaml.org
> > > http://lists.ocaml.org/listinfo/platform
> > >
> > >
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ocaml.org/pipermail/platform/attachments/20150508/d5a96421/attachment.html>