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

Fix opam install on a local directory not updating pinned packages' metadata #6209

Open
wants to merge 5 commits into
base: master
Choose a base branch
from

Conversation

kit-ty-kate
Copy link
Member

@kit-ty-kate kit-ty-kate commented Sep 24, 2024

Fixes #5567
Fixes #4507
Queued on #6438

I have no idea why for_view was introduced in 9b2a67f but i've tested opam 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 through simulate_local_pinning which didn't take into account that some packages being pinned are already pinned. In that case the reinstall field must be updated to ensure the rest of the code knows that package should be reinstalled.

Copy link
Collaborator

@rjbou rjbou left a 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.

@kit-ty-kate kit-ty-kate force-pushed the fix-opam-install-local-pinned branch 4 times, most recently from 3a911c1 to a95f45f Compare October 22, 2024 21:18
@kit-ty-kate kit-ty-kate requested a review from rjbou October 22, 2024 21:19
@kit-ty-kate kit-ty-kate force-pushed the fix-opam-install-local-pinned branch from a95f45f to 5e531b5 Compare October 22, 2024 21:56
### ::: 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).
Copy link
Collaborator

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.

Copy link
Member Author

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.

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

👍

@kit-ty-kate kit-ty-kate changed the title Fix "opam install <local_dir>" not updating pinned packages' metadata Fix opam install on a local directory not updating pinned packages' metadata Dec 16, 2024
@kit-ty-kate kit-ty-kate force-pushed the fix-opam-install-local-pinned branch from fd9e61e to ffc0d4f Compare February 25, 2025 21:58
@kit-ty-kate kit-ty-kate requested a review from rjbou February 25, 2025 21:59
@kit-ty-kate kit-ty-kate force-pushed the fix-opam-install-local-pinned branch from ffc0d4f to f5b80ec Compare March 14, 2025 21:59
@kit-ty-kate
Copy link
Member Author

rebased on master

@rjbou
Copy link
Collaborator

rjbou commented Mar 27, 2025

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.

We need to upgrade the package to keep in sync the switch.

@rjbou rjbou force-pushed the fix-opam-install-local-pinned branch from f5b80ec to 294713e Compare March 27, 2025 15:51
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
Copy link
Collaborator

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.

Copy link
Member Author

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?

Copy link
Member Author

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

@kit-ty-kate kit-ty-kate added PR: QUEUED Pending pull request, waiting for other work to be merged or closed and removed PR: QUEUED Pending pull request, waiting for other work to be merged or closed labels Mar 28, 2025
…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.
@kit-ty-kate kit-ty-kate force-pushed the fix-opam-install-local-pinned branch from e3b74f6 to f50852d Compare March 31, 2025 11:44
@kit-ty-kate kit-ty-kate requested a review from rjbou March 31, 2025 11:44
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
2 participants