[ocaml-platform] Dev Version as Package?

[Trevor Smith]

Wow! Excited to see everyone jumping in. I appreciate everyone's
contributions. Helpful to see how different people are dealing with this.

@Thomas you pointed me in the direction of what I needed. I see that I
overlooked that on reading about repositories, and it is documented at:
http://opam.ocaml.org/doc/Manual.html#Repospecification

What I want to do is emulate Maven SNAPSHOT functionality (described here:
http://stackoverflow.com/questions/5901378/what-exactly-is-a-maven-snapshot-and-why-do-we-need-it
).

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.

Thoughts? Thanks again for everyone's input.

Trevor

On Tue, May 5, 2015 at 3:42 PM, Thomas Braibant <thomas.braibant at gmail.com>
wrote:

> Hi,
>
> We faced this issue at work too. The typical issue is "I want to depend on
> this particular branch of a third party repository". Pinning packages
> locally would work, but we want something that we can push on CI and build
> servers, and share in the team (and keep in the git history of the
> project).
>
> The solution we came up with is as follows: in our dev repository
> `project`, we keep a particular opam repository `project/opam-repository`.
> This repository contains shadow opam packages. For instance, if I want to
> depend on branch bar of a public project foo, we just add a new version of
> the opam package for foo in `project/opam-repository/packages`, with an
> explicit version number, and with an url like `path-to-project-foo#bar`.
> Then, we keep a opam file in `project` that specifies the explicit
> dependencies (given version of public package) and the dev dependencies
> (home brewed version of public packages). The dev dependencies can only be
> met using the shadow opam files.
>
> Then, our CI/build scripts use something like
> ```
> opam remote remove shadow-opam-repository
> opam remote add shadow-opam-repository ./opam-repository
> opam update
> opam pin add --no-action project ./ -y
> opam install --deps-only project -y
> ```
>
> Changing version of packages for all devs and our servers is done by
> commiting changes either to the opam-repository or to the opam file in the
> project.
>
> Hope that helps.
> Thomas
>
>
>
>
>
> On Tue, May 5, 2015 at 9:19 PM, Malcolm Matalka <mmatalka at gmail.com>
> wrote:
>
>> Each project I have has its own opam repo which I put as higher priority
>> to the basic one.  Does this do what you want?
>>
>> Trevor Smith <trevorsummerssmith at gmail.com> writes:
>>
>> > 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
>> _______________________________________________
>> 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/20150505/e48dc3cd/attachment.html>