[ENH] Option to re-lock a project with the smallest number of changes

[maximlt]

Say you’ve got a project that is locked and that you want to update the version of one of its direct dependencies. You then change its specification:

name: Project
packages:
  - python=3.8
  - notebook
  - panel
-  - pandas=1.2
+  - pandas=1.3
env_specs:
  default: {}

Now it's time to lock the project again. It would be really nice if there was an option to re-lock the project so that the new lock has as few updates as possible. In the example and with this option, the new lock may:

• just have the updated version of pandas, and that's it
• or, have the updated version of pandas and potentially some new dependencies added in 1.3 and/or newer versions of its dependencies if those that were locked prove not to longer satisfy the 1.3 requirements.

[maximlt]

I've just discovered the --no-update-deps option flag of conda update, which seems that it might be useful for this feature.

[AlbertDeFusco]

Thanks for this. I believe I can develop a minimal and repeatable example/test where a requested package (and the lock) can be updated but not its dependencies (unless there is a conflict)

Conda lock has a flag --update <pkg> that also be useful to us

[ericdill]

so that the new lock has as few updates as possible

can you say more about what's motivating the desire to minimize the changes? i'm sure there are many reasons. i'm interested in enumerating them because i suspect that not all of them require the same kind of solution and maybe we can get creative with some of them

[maximlt]

I'm also pretty sure there are many reasons why one would want to define how exactly an environment should be relocked.

One that comes to mind and I think motivated this issue is when you have an application and just want to bump the version of one of its dependencies (to use a new feature, avoid a CVE or bug). In that case you may just want to make the smallest change possible which would be, if possible, just bumping that version. If you feel more confident you may instead want to bump that dependency and let of of its transitive dependencies loose and relock them all with whatever versions the solver finds.

Another motivation for specifying which packages you want to relock is when you decide to totally upgrade an application. Instead of relocking them all, you can go one by one and fix the issues (API changes, warnings) as they come, instead of having to deal with all of them at the same time.

A case we have encountered is something going wrong with a transitive dependency. In our case the pinned version was removed from the channel, but you can also imagine we'd have liked to bump it due to a CVE. In that case it'd be nice to be able to bump it specifically.

PDM offers a few different upgrade strategies that are similar to these suggestions: https://pdm.fming.dev/latest/usage/dependency/#about-update-strategy