[question] Workflow to update single dependencies in a lockfile

[fschoenm]

What is your question?

Hi, I have a question regarding lockfiles that is not yet clear to me and I haven't really found the answer so far.

This is based on a real-world use case:

• We have a product (conan consumer) with a handful of dependencies, one of them being boost. It's using and compatible with boost/1.82.0, which is on our remote, but introducting boost/1.85.0 leads to a compile error.
• We want to have a conan.lock to lock the dependencies so that uploading boost/1.85.0 to our remote doesn't break the build.
• After fixing the compile issues with boost/1.85.0, we want to update this specific dependency to the latest version allowed by the version range but keep all other dependencies at the version they are.

What's the recommended workflow for this? It doesn't seem possible out of the box?

• In [bug] conan lock create --update doesn't appear to work #16267 (comment), I found the recommendation to use conan .... --update --lockfile="" --lockfile-out="conan.lock but that would update all dependencies to the latest version. Using conan .... --update boost* --lockfile="" --lockfile-out="conan.lock would limit that somehow but IMO still update all dependencies found in the local cache.

• Using conan lock add --requires boost/1.85.0 does kind of work but now the lockfile contains both the old boost version (including the revision) and the new boost version (but without a revision). What does it mean that the old version is still in the lockfile and why isn't it replaced? Also, I'd like to let conan resolve the valid version range instead of manually specifying the version (and revision) of a package.

• One workflow that seems to do what I want but seems overly complicated for an IMO common use case is this:

  $ conan lock remove --requires boost/*
  $ conan install ... --lockfile-partial --lockfile-out conan.lock
  

  I think it did what I wanted but I'm not sure because I couldn't find this workflow in the documentation. If this is the correct workflow, I also wonder if it would be possible to simplify it into a command that specifically updates a single dependency by resolving the valid version range?

Have you read the CONTRIBUTING guide?

• I've read the CONTRIBUTING guide

[memsharded]

Hi @fschoenm

Thanks for your question

Using conan lock add --requires boost/1.85.0 does kind of work but now the lockfile contains both the old boost version (including the revision) and the new boost version (but without a revision). What does it mean that the old version is still in the lockfile and why isn't it replaced? Also, I'd like to let conan resolve the valid version range instead of manually specifying the version (and revision) of a package.

Note that a dependency graph can contain multiple different versions of the same package. This happens for example when tool_requires (which are private) depends on different versions of other packages, for example some tool_require might have a self.requires("boost/[>=1.81 <1.83]"), while other tool_requires can contain a self.requires("boost/[>=1.81 <1.90]").
The lockfile storing both versions allows to naturally resolve and correctly lock both different versions of boost for the different tool_requires. The same situation can happen in "host" dependencies whenever visible=False traits are used, so it is important that lockfiles can also manage those scenarios.

For most cases it wouldn't matter if you have that older version there, the resolution will be correct, and you can later get rid of it if you want with the --lockfile-clean argument.

The other alternative is what you suggested, you can also explicitely conan lock remove, but yes, it requires an extra step. I agree it could be simplified, with an update, lets do it. Still, probably it is not really necessary, and in some cases it might be counter-productive or destructive (the cases where the graph actually has different versions and you want to update only one of them)

[fschoenm]

The other alternative is what you suggested, you can also explicitely conan lock remove, but yes, it requires an extra step. I agree it could be simplified, with an update, lets do it.

Thanks for explanation @memsharded , looing forward to that :)