New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Share a set of dev repositories #1734

Open
Drup opened this Issue Sep 17, 2014 · 3 comments

Comments

Projects
None yet
4 participants
@Drup
Contributor

Drup commented Sep 17, 2014

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

This comment has been minimized.

Show comment
Hide comment
@avsm

avsm Sep 17, 2014

Member

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.

Member

avsm commented Sep 17, 2014

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 AltGr added the AREA: DESIGN label Sep 18, 2014

@AltGr AltGr added this to the Next milestone Sep 18, 2014

@AltGr

This comment has been minimized.

Show comment
Hide comment
@AltGr

AltGr Sep 18, 2014

Member

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

Member

AltGr commented Sep 18, 2014

@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

This comment has been minimized.

Show comment
Hide comment
@dbuenzli

dbuenzli Sep 18, 2014

Contributor

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.

Contributor

dbuenzli commented Sep 18, 2014

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment