[bug] conan lock create --update doesn't appear to work

[rconde01]

Describe the bug

conan_update_revision.zip

Conan 2.3
The --update option says:

Will install newer versions and/or revisions in the
local cache for the given reference, or all in case no
argument is supplied. When using version ranges, it
will install the latest version that satisfies the
range. Also, if using revisions, it will update to the
latest revision for the resolved version range.

In the attached test, I have a lock file which references a recipe revision which is not the newest revision in conan center. I call conan create lock --update ... and I would have expected the revision to be updated to the latest. However, it does not change.

How to reproduce it

1. Unzip the attachment
2. run python test.py

test.py setups up a virtual environment and then installs conan and sets CONAN_HOME to a relative dir. The test then attempts to update the lock to the latest revision but nothing happens.

[memsharded]

Hi @rconde01

Thanks for your feedback.

I think this is the need of further clarification in the docs. Let me try to clarify:

The lockfile fixes the versions and revisions that are used from dependencies. Its purpose is to effectively block the update of those versions and revisions when these new things are published.

On the other hand, the --update is intended to update the local cache compared with the server, because Conan by default will resolve in the cache, if things are found there, it avoids going to the server to check.

Both are kind of opposing forces, but they can also work together without conflicting, and this is the case of partial lockfiles. A lockfile can lock some things, but not others. In this case, it is perfectly valid to have both a lockfile that completely locks what it defines, avoiding them to use new versions or revisions, and at the same time can --update the local cache with new server versions that are not contained in the lockfile, and then stored them in an update lockfile. This works by default in conan lock create where --lockfile-partial is implicit, and any command that explicitly provides the --lockfile-partial argument.

What is not possible is to update a locked version/revision of a lockfile. That is intended to be fixed and never be modified, no matter what happens in the cache or in the remotes, it is the reason to use a lockfile. It is not possible to both lock and not lock at the same time.

If the intention is to create a new lockfile with updated versions, then this is also possible, it is the equivalent of not locking, so using the same conan command, but making sure the initial lockfile is not used, with conan .... --update --lockfile="" --lockfile-out="conan.lock. That will overwrite the existing conan.lock with the new, updated versions.

[rconde01]

To clarify, when I say "update a lock file", I mean to use a lock file as input, generating a new lock file and overwriting the original. Putting the meaning of --update aside, I think there is a use case for allowing granular updates of revisions within a lock file.

• The existing revision no longer builds
  • Maybe a change is needed for a new version of a compiler, or because some other logic broke due to an external dependency
• A new revision provides new options you want to use

You may want to update revisions in these cases, while staying on the same version of the library. Additionally, you don't necessarily want to update the revisions of EVERYTHING in the lock file which would potentially require every package to be rebuilt.

So, I think having the capability to do that via a conan command would be useful. I need to try it, but I think a workaround is to:

1. generate a conanfile with the depedencies you want to update,
2. Create a lock file from that conanfile
3. Merge that lock file into the original lock file

[memsharded]

You may want to update revisions in these cases, while staying on the same version of the library. Additionally, you don't necessarily want to update the revisions of EVERYTHING in the lock file which would potentially require every package to be rebuilt.

The problem is that there are no semantics for this, how to know that you want to update only the revisions, but not the versions?

In any case, I think there is a way to achieve this. You can remove the revisions you want to "free" from a lockfile and feed it, and Conan will be able to resolve to the non-locked revisions while keeping the versions locked, maybe you want to give that a try.

[rconde01]

The problem is that there are no semantics for this, how to know that you want to update only the revisions, but not the versions?

My initial thought was that e.g. --update boost/1.81.0 would do this. You could image though a --update-revision boost/1.81.0.

In any case, I think there is a way to achieve this. You can remove the revisions you want to "free" from a lockfile and feed it, and Conan will be able to resolve to the non-locked revisions while keeping the versions locked, maybe you want to give that a try.

Hmm...I think the problem there is maybe the revisions of any dependencies of the thing you want to update. I guess I would expect to update all those revisions as well, but I admit that seems a bit subjective.

[rconde01]

Upon further reflection, I guess targeting just the specific reference makes sense since theoretically that package shouldn't care about the package revisions of it's dependencies.