Share a set of dev repositories

[Drup]

See this discussion for the underlying issue.
Basically, We have a set of git urls we want to share as dev version of some packages. Each package is pinnable independently, so it contains its own opam file.

Some times ago, we put up a repository containing all these packages, but the current situation is that opam files are duplicated in this opam repository and in each git repository.

In practice we could solve this by some automation, but I think it's possible to do better at opam level. One solution could be to have only the url of the git repository and let opam fetch the opam file there.

I think the mirage project used to have the same issue. @avsm ?

cc @balat

[avsm]

Yeah, we have a https://github.com/mirage/mirage-dev for the same purpose

The main source of duplication is the opam file itself, but it is useful to have the opam remote to bump version numbers as well. Some automation around this would be useful, but it might be better to let the dust settle on the OPAM 1.2 workflow before diving into it in detail (since OPAM 1.2 does improve the state of affairs by probing for a remote opam file in the pinned repo).

On 17 Sep 2014, at 14:12, Gabriel Radanne notifications@github.com wrote:

See this discussion for the underlying issue.
Basically, We have a set of git urls we want to share as dev version of some packages. Each package is pinnable independently, so it contains its own opam file.

Some times ago, we put up a repository containing all this packages, but the current situation is that opam files are duplicated in this opam repository and in each git repository.

In practice we could solve this by some automation, but I think it's possible to do better at opam level. One solution could be to have only the url of the git repository and let opam fetch the opam file there.

I think the mirage project used to have the same issue. @avsm ?

cc @balat

—
Reply to this email directly or view it on GitHub.

[AltGr]

@avsm: Agreed

Note that fetching opam files doesn't really scale since you'd have to download all of them before you could consistently call the solver. That's one of the reason why I started implementing the new pinning and saner handling of opam files.

For me having an opam-admin option that extracts opam files sounds like a good alternative: done only once, and it already downloads and extracts the archives when changed. That won't work with a bare git repo though and requires some heavier infrastructure.

[dbuenzli]

As loosely suggested in this comment one option would be to forget about using dev repos in these cases and provide a simple way to bulk add and remove a set of pins. The former can already be solved by using opam switch import the latter doesn't. Something like this.

opam pin import FILE
opam pin remove --file FILE

In contrast to the opam repo approach, one thing that this wouldn't handle though is the addition/removal of pacakges (you'd have to redowload the published file). This could be aleviated by having pin sources:

opam pin source add URL
opam pin source remove URL

Where URL dereferences to a list of pins, but I'm not sure it's a good idea to add yet another concept to opam.