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

Add package version constraints #392

Closed
samoht opened this Issue Mar 24, 2015 · 6 comments

Comments

Projects
None yet
4 participants
@samoht
Member

samoht commented Mar 24, 2015

Now that we only support opam 1.2, we can use the syntax <package><relop><version> (where relop is =, <=, >=, ...) on the command-line to express package version constraints. We should start using it in the tool, to ensure that the right version are present at configuration time. Not sure we can have && constraints, need to check with @AltGr.

Note: I think we want to keep the up-constraint opened so that we don't have to release a new version of the tool for each library release. So we would update the version constraints only when we have incompatible API changes in the library. Which should be fine if we always have the latest version of the tool installed and running. So we might need to add additional checks in the mirage tool to check that it is up-to-date (by calling opam list mirage?).

@hannesm

This comment has been minimized.

Show comment
Hide comment
@hannesm

hannesm Jul 3, 2016

Member

related to #499

Member

hannesm commented Jul 3, 2016

related to #499

@AltGr

This comment has been minimized.

Show comment
Hide comment
@AltGr

AltGr Jul 4, 2016

You can't have such constraints, but e.g. opam install 'foo>=3' 'foo<4' would work.
For more complex constraints, you'll need to pin+edit a package with the appropriate depends: field, or use switch import.

AltGr commented Jul 4, 2016

You can't have such constraints, but e.g. opam install 'foo>=3' 'foo<4' would work.
For more complex constraints, you'll need to pin+edit a package with the appropriate depends: field, or use switch import.

@Drup

This comment has been minimized.

Show comment
Hide comment
@Drup

Drup Jul 4, 2016

Member

IIRC, this is already supported on the functoria side, in the package field, so it just needs to update mirage.ml.

Member

Drup commented Jul 4, 2016

IIRC, this is already supported on the functoria side, in the package field, so it just needs to update mirage.ml.

@samoht

This comment has been minimized.

Show comment
Hide comment
@samoht

samoht Jul 5, 2016

Member

On a related note, @Drup do you think adding a val pkg: ?opam:string -> ?ocamfind:string -> pkg combinator would make sense?

Member

samoht commented Jul 5, 2016

On a related note, @Drup do you think adding a val pkg: ?opam:string -> ?ocamfind:string -> pkg combinator would make sense?

@Drup

This comment has been minimized.

Show comment
Hide comment
@Drup

Drup Jul 5, 2016

Member

Hum, that would be an incompatible change, isn't it ? It clearly makes more sense, but ultimately, it wouldn't change much. In most cases, the opam and ocamlfind information should be bundled inside the configurable that needs them.

Member

Drup commented Jul 5, 2016

Hum, that would be an incompatible change, isn't it ? It clearly makes more sense, but ultimately, it wouldn't change much. In most cases, the opam and ocamlfind information should be bundled inside the configurable that needs them.

@hannesm

This comment has been minimized.

Show comment
Hide comment
@hannesm

hannesm Nov 21, 2016

Member

I do appreciat this issue, and solved it in mirage/functoria#82. I will close this issue, and hope discussion will happen over in the actual PR.

Member

hannesm commented Nov 21, 2016

I do appreciat this issue, and solved it in mirage/functoria#82. I will close this issue, and hope discussion will happen over in the actual PR.

@hannesm hannesm closed this Nov 21, 2016

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