[ocaml-platform] Dev Version as Package?

[Trevor Smith]

@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.

Thanks.

Trevor

On Wed, May 6, 2015 at 4:51 AM, Thomas Braibant <thomas.braibant at gmail.com>
wrote:

> Hi,
>
> 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.
>>
>>
> 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).
>
> 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
>
> ```
> opam-version: "1.2"
> ...
> depends: [
>   "asn1-combinators" { = "0.1.1" }
>   ...
>   "foo" { git: "path-to-git/foo#bar"}
> ]
> ```
>
> 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.
>
> Thoughts?
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ocaml.org/pipermail/platform/attachments/20150506/2d7d86f3/attachment.html>