[ocaml-platform] Dev Version as Package?

[Thomas Braibant]

Well, this single repository needs to be added once per project. And it
contains some redundant information with respect to your main repository.
For instance, you might be tempted to duplicate the descr file and some
part of the opam file. With the url in opam file scheme, you wouldn't need
to duplicate this, since you would be able to get all the relevant
information in the opam file of the target package.



On Wed, May 6, 2015 at 3:22 PM, Trevor Smith <trevorsummerssmith at gmail.com>
wrote:

> @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/7cb86595/attachment-0001.html>