Rationale behind upgrading all dependent packages when pinning a package to the already installed version

[MSoegtropIMC]

In Coq Platform CI (which is heavily opam based) I see a change in behaviour after updating to opam 2.2: when I pin a package to the version it already has, opam upgrades all packages depending on this package. See e.g. this CI log:

https://github.com/coq/platform/actions/runs/10037269557/job/27736704911#step:5:721

Before Coq 8.15.2 has been installed already - at the point above it is pinned to 8.15.2 which has the effect you see below this point in the log.

This was not so in opam 2.1.X. I can live with this - I now added --no-action to the pin commands (CI is still running but I guess this has the desired effect), but I wonder if this change is intended and if so what the rationale behind it is.

A note: I install many packages in parallel with a single request, both for performance reasons and also to catch version issues early. Some critical packages (like Coq) I need to pin and I do this after the installation with individual pin commands. Is there a better way of doing this?

[kit-ty-kate]

I'm not sure the change of behaviour was intentional, however --no-action is indeed something that you'd want to use in your case anyway.
This bug doesn't seem critical but we'll have a look at it when we have some time.

A note: I install many packages in parallel with a single request, both for performance reasons and also to catch version issues early. Some critical packages (like Coq) I need to pin and I do this after the installation with individual pin commands. Is there a better way of doing this?

You mean like pinning several packages in a single command or something else? Otherwise i'm not sure, i think pinning is probably the best way i can think of right now. Just in case that helps we've added opam pin add --current <pkgname> but it's the same thing you'd have to call it for every packages. It only simplifies things a little as you don't have to pass the version number anymore. (just be aware that the behaviour of --current is a bit different from normal version pin)

[MSoegtropIMC]

You mean like pinning several packages in a single command or something else?

What I want to do is install many packages in parallel and pin some of them to specific versions. Currently I do this in a two step process: first install the many packages in parallel and then pin some packages with a separate opam call.

[kit-ty-kate]

ah, you'd want something like opam install <pkg1> pin:<pkg2> ... <pkgn> where pkg2 would be pinned but not the other ones?
(actually looking at the scripts in coq/platform it seems to be exactly what you already do internally)

From a UX perspective i'm not sure i like this, however we could think of supporting opam pin add <pkg1> <pkg2> ... <pkgn> similarily to #5537 but we should think about it a bit more as the syntax for pin add is already pretty bloated with regard to the number of options it can take. Maybe we could have a separate subcommand for it. We can think about it, however one thing is that performance-wise opam pin add --no-action should be negligible already so i'm not sure whether allowing to pin multiples at a time would be an improvement for you.

[MSoegtropIMC]

Thanks - I was not aware of the opam install pin:<pkg> syntax. This is not what I am currently doing. I mark packages to be pinned with a prefix PIN. in my package lists but then I take this apart here:

https://github.com/coq/platform/blob/4a04a4dbe2c30e7ef2116066f0e6a2fadf90c623/shell_scripts/build.sh#L44

I guess I could just replace the PIN. markers with pin: and pass this list to opam install without any processing.

From a UX perspective i'm not sure i like this

What is wrong with this besides that it is not so obvious?

[kit-ty-kate]

I was not aware of the opam install pin:<pkg> syntax

no no, what i meant is "we could do it but this feature does not exist currently"

[kit-ty-kate]

What is wrong with this besides that it is not so obvious?

this + mixing the pin mechanic with the install command is currently only done for local projects and i feel like allowing it more generally would add a confusing feature in terms of design and would tie more knots between the two mechanics in our codebase internally. Pinning is a tricky feature and can get arbitrarily complicated (e.g. #3202) and adding such a syntactic sugar feels to be like a trap in terms of feature creep.