Skip to content
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

opam 2.1.0 has different behaviours on macOS on packages with mismatching version field #4780

Closed
kit-ty-kate opened this issue Jul 31, 2021 · 6 comments · Fixed by #4968
Closed

Comments

@kit-ty-kate
Copy link
Member

$ opam repository set-url --strict default "git://github.com/GgnDpSngh/opam-repository.git#ef9a4b1448581b3de004c85ce9409eaacee2bdd0"
[default] Initialised
[ERROR] In /home/opam/.opam/repo/default/packages/elina/elina.1.1/opam:
        This file is for package 'elina.1.1' but has mismatching fields 'version:1.3.
[ERROR] Strict mode: aborting
[ERROR] Could not update repository "default": OpamStd.OpamSys.Exit(30)

This succeeds (see #4779), but now on Linux:

$ opam pin add -k version -yn elina.1.1 1.1
elina is now pinned to version 1.1

succeeds, however on macOS the package does not even exist anymore (it existed before, see https://opam.ocaml.org/packages/elina/):

$ opam show elina
[ERROR] No package matching elina found
@kit-ty-kate
Copy link
Member Author

kit-ty-kate commented Dec 16, 2021

I was able to reproduce:

$ opam repo add --strict tmp "git://github.com/GgnDpSngh/opam-repository.git#ef9a4b1448581b3de004c85ce9409eaacee2bdd0"
[tmp] Initialised
[ERROR] In /Users/kit_ty_kate/.opam/repo/tmp/packages/elina/elina.1.1/opam:
        This file is for package 'elina.1.1' but has mismatching fields 'version:1.3.
[ERROR] Strict mode: aborting
[ERROR] Could not update repository "tmp": OpamStd.OpamSys.Exit(30)
[ERROR] Initial repository fetch failed


$ opam remote
[NOTE] These are the repositories in use by the current switch. Use '--all' to see all configured repositories.

<><> Repository configuration for switch tmp ><><><><><><><><><><><><><><><>  🐫
 1 default git://github.com/ocaml/opam-repository.git


$ opam repo set-url --strict default "git://github.com/GgnDpSngh/opam-repository.git#ef9a4b1448581b3de004c85ce9409eaacee2bdd0"
[default] Initialised
[ERROR] In /Users/kit_ty_kate/.opam/repo/default/packages/elina/elina.1.1/opam:
        This file is for package 'elina.1.1' but has mismatching fields 'version:1.3.
[ERROR] Strict mode: aborting
[ERROR] Could not update repository "default": OpamStd.OpamSys.Exit(30)


$ opam repo
[NOTE] These are the repositories in use by the current switch. Use '--all' to see all configured repositories.

<><> Repository configuration for switch tmp ><><><><><><><><><><><><><><><>  🐫
 1 default git://github.com/GgnDpSngh/opam-repository.git#ef9a4b1448581b3de004c85ce9409eaacee2bdd0

$ opam show elina
[ERROR] No package matching elina found

$ opam show dune
[ERROR] No package matching dune found

There seems to be a weird change of behaviour between opam repo set-url and opam repo add where the first one sets the url dispite suceeding and the second one does not add the repository.

On macOS the repository state seems to have been set to an empty one whereas on linux it seems to have ignored the failure.

Tested with opam master (ab530f8)

@rjbou
Copy link
Collaborator

rjbou commented Dec 16, 2021

ok, it's the strict mode that is making it fail, i see. I've tried without it.

@rjbou
Copy link
Collaborator

rjbou commented Dec 16, 2021

I can reproduce, on linux too

@rjbou
Copy link
Collaborator

rjbou commented Dec 16, 2021

I can be better handled with the new opam repo --no-action : in case of add & set-url that fail at fetch (or check with strict mode), keep repos and mark them as non initialised

@rjbou rjbou linked a pull request Dec 16, 2021 that will close this issue
@kit-ty-kate
Copy link
Member Author

I don’t think this is a good solution. I’d much rather fail early and not do any modification when it fails and have the same behaviour between add and set-url.
Otherwise that means users wouldn’t be able to revert what they did

@rjbou
Copy link
Collaborator

rjbou commented Dec 16, 2021

Makes sense... So we keep the may fail after setting an url just when specifically user set --no-action

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
2 participants