-
Notifications
You must be signed in to change notification settings - Fork 373
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
Fix opam install on a local directory not updating pinned packages' metadata #6209
base: master
Are you sure you want to change the base?
Fix opam install on a local directory not updating pinned packages' metadata #6209
Conversation
ce39103
to
e8fc621
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I reviewed commit per commit, it's better to look at comments per commit.
I'm not sure about the third commit (reinstall packages), it raises a good question. we want to update the opam file internally, but do we want to upgrade the package itself? Usually, when users use --deps-only
they don't want to launch an install of given package (no need, or don't want to double compile it). When the package is already installed, there is the "we want to have a consistent state" that leads us to want to upgrade the package. From CLI perspective, it is more consistent to not upgrade the package.
Maybe a note or warning to highlight the situation package updated internally, if you really want to reinstall it, launch opam install pkg is better than a full reinstall triggered by --deps-only
.
3a911c1
to
a95f45f
Compare
a95f45f
to
5e531b5
Compare
### ::: behaviour when the package is not pinned | ||
### opam install ./pin-change | ||
pin-change is now pinned to git+file://${BASEDIR}/pin-change#master (version dev) | ||
[NOTE] Ignoring uncommitted changes in ${BASEDIR}/pin-change (`--working-dir' not specified or specified with no argument). |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
If we have a more fine grained handling of pin update (opam file vs source update), we can even remove that note if only the uncommitted opam file is updated, as now we have the information.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
same as with https://github.com/ocaml/opam/pull/6209/files#r1815454356 i believe. I think those two improvements can be their own tickets to be fixed later.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
👍
fd9e61e
to
ffc0d4f
Compare
ffc0d4f
to
f5b80ec
Compare
rebased on master |
We need to upgrade the package to keep in sync the switch. |
f5b80ec
to
294713e
Compare
src/client/opamAuxCommands.ml
Outdated
OpamSwitchState.opam_opt st pinned_pkg, | ||
OpamFile.OPAM.read_opt nf.pin.pin_file | ||
with | ||
| Some opam0, Some opam -> | ||
(* Keep synchronised with [OpamFile.OPAM.pp_raw_fields] added |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
i'm wondering if it would be better to have a function in OpamFile.OPAM
that does all these additions in order to compare (or just returns the new opam file?), like that it's easier to keep synchronised as they would be in the same module / near in the code.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I've added two fixup commits (to cleanup of course) exploring that idea.
The first one rewrites the comparison to be more efficient (2 read instead of 4), and more correct.
In particular the available
field was bugging me. The pp_minimal_opam_version
function would rewrite the available field but i can't find any good reason for this.
This function was originally added in 1d32477 + ca84c3a but i can't find any reasoning for this change aside from "consistency". I personally think this makes the whole thing less consistent by introducing differences between original file and rewritten files, which is nearly impossible to detangle.
For this reason i chose to remove this part of the code which makes for a needed simplification, in my opinion.
What do you think?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I extracted the OpamFile.OPAM
function extraction idea to #6446 as i think we need more time to think about this
294713e
to
e3b74f6
Compare
…l opam file changes while being pinned
…ected and ensure showing local opam files is working as expected
…ages' metadata The reinstall field from the switch state wasn't updated according to the implicit pin and thus opam didn't think there was anything to do.
e3b74f6
to
f50852d
Compare
Fixes #5567
Fixes #4507
Queued on #6438
I have no idea why
for_view
was introduced in 9b2a67f but i've testedopam show
and i'm not seeing any breaking nor does the testsuite.The bypass here was causing local packages to be put in the
already_pinned
set. However this set is only used to update the<switch>/.opam-switch/sources/<pkg>
directory, not the<...>/overlay
directory as the assumption with this set is that the package description hasn't change.Removing that bypass makes the function much more consistent.
The
reinstall
bit is a bit easier to understand: when using--deps-only
or--show-action
, the codepath goes throughsimulate_local_pinning
which didn't take into account that some packages being pinned are already pinned. In that case thereinstall
field must be updated to ensure the rest of the code knows that package should be reinstalled.