Skip to content
New issue

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

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

Already on GitHub? # to your account

opam install --locked silently ignores the --locked option #4313

Closed
brendanlong opened this issue Aug 14, 2020 · 7 comments · Fixed by #5079 or #5148
Closed

opam install --locked silently ignores the --locked option #4313

brendanlong opened this issue Aug 14, 2020 · 7 comments · Fixed by #5079 or #5148
Assignees
Milestone

Comments

@brendanlong
Copy link

The behavior of install --locked is really confusing, especially because there's no indication that anything is wrong.

The thing I would expect to work:

# Pin package(s) in the current repo but don't install deps yet
opam pin add -y -n .
# Install depexts
opam depext mypackage -y
# Now install deps
opam install . -y --locked

In this case, the --locked argument does absolutely nothing and the deps are installed only using mypackage.opam.

After reading opam install --help, I realized that --locked only works for with opam pin:

# Pin package(s) in the current repo but don't install deps yet
opam pin add -y -n .
# Install depexts
opam depext mypackage -y
# Now install deps in a really convoluted way
opam pin remove -y mypackage
opam pin add -y --locked .

There are two things I'd propose changing:

  1. Please make opam install --locked use the lock file
  2. Until (1) is done, make opam install --locked return an error message instead of silently ignoring the argument
@rjbou
Copy link
Collaborator

rjbou commented Aug 17, 2020

Opam install uses the lock file when the option is given.
What opam version do you use?
Can you share the output of the install locked command? Also, you pin a local directory, is it a git or path pin?

@rjbou
Copy link
Collaborator

rjbou commented Oct 9, 2020

Any news on this one ?

@AltGr
Copy link
Member

AltGr commented Jan 15, 2021

There seems to indeed be a bug here where the auto update done on opam install DIR doesn't handle the changes between the .opam file (which the package is currently pinned as) and the .opam.locked file:

% opam install . --locked
[NOTE] Ignoring uncommitted changes in /foo/bar (`--working-dir' not active).
[bar.0.10] synchronised (no changes)

@dra27 dra27 added this to the 2.1.0~rc milestone Jan 22, 2021
@dra27 dra27 modified the milestones: 2.1.0~rc, 2.2.0~alpha, 2.1.1 Feb 5, 2021
@jvillard
Copy link
Contributor

jvillard commented Jun 2, 2021

Not sure if it's the same issue (should I open a new one?) but I have another case where --locked doesn't use the lock file:

opam install --deps-only /path/to/opam/foo.opam --locked

This ignores the lock file in "/path/to/opam/foo.opam.locked". A workaround is to use opam install --deps-only /path/to/opam/foo.opam.locked instead but I'm quite sure the --locked command used to work when our opam files weren't in a separate opam/ directory so my guess is that opam doesn't look in the correct place for a .locked file?

facebook-github-bot pushed a commit to facebook/infer that referenced this issue Jun 3, 2021
Summary:
This seems like a bug in opam, probably started after we moved the opam
files to opam/ in D27326495 (673c944). I reported the strange behaviour in
ocaml/opam#4313 (comment).

Reviewed By: rgrig

Differential Revision: D28837624

fbshipit-source-id: f91a58dbc
@rjbou
Copy link
Collaborator

rjbou commented Jun 8, 2021

@jvillard As you give opam an opam file, it takes that opam file, and don't look for the locked one. With opam install --deps-only /path/to/opam --locked, it should be ok.

@dra27 dra27 modified the milestones: 2.1.1, 2.1.2 Sep 17, 2021
@dra27 dra27 modified the milestones: 2.1.2, 2.1.3 Nov 19, 2021
@rjbou rjbou mentioned this issue Dec 14, 2021
@rjbou
Copy link
Collaborator

rjbou commented May 23, 2022

The update/upgrade of locked pins is fixed by #5080, and initial issue should be fixed by #5079, see test dif
@brendanlong

@rjbou
Copy link
Collaborator

rjbou commented May 23, 2022

And the second, @jvillard one, is fixed by #5148

sim642 added a commit to goblint/analyzer that referenced this issue Jun 22, 2022
sim642 added a commit to goblint/analyzer that referenced this issue Jun 22, 2022
# for free to join this conversation on GitHub. Already have an account? # to comment
Projects
None yet
Development

Successfully merging a pull request may close this issue.

5 participants