[bug] conan lock create --update does not pull down latest version

[geir-t]

Environment details

• Operating System+version: Ubuntu 22.04.1 LTS
• Compiler+version:
• Conan version: conan 2.0.10
• Python version: 3.10.12

Steps to reproduce

Hi

conan lock create --update does not pull down latest version from remote if I have lesser version in cache. If I remove the package from cache it works as expected.

Start with empty cache, lock create works as expected, picking 0.1.0+44.sha.43a1bb8

$ conan list package
Local Cache
  ERROR: Recipe 'package' not found

user$ conan search package/*@company -r company-remote
company-remote
  package
    package/0.1.0+43.sha.43a1bb8@company
    package/0.1.0+44.sha.43a1bb8@company

conan lock create .  --lockfile=""  --update

$ git diff
diff --git a/conan.lock b/conan.lock
index 2baea52..6b6f9e5 100644
--- a/conan.lock
+++ b/conan.lock
@@ -22,6 +22,6 @@
         "b2/4.9.6#2e02945ad41739b8051247d14fe8297d%1689863625.776"
     ],
     "python_requires": [
-        "package/0.1.0+43.sha.43a1bb8@company#c525c55123b4d0912b0fbc5e2f1f9b10%1693388200.916"
+        "package/0.1.0+44.sha.43a1bb8@company#c525c55123b4d0912b0fbc5e2f1f9b10%1693540232.223"
     ]
 }

If I first download 0.1.0+43.sha.43a1bb8 to cache it does not pick 0.1.0+44 as expected.

$ conan list package
Local Cache
  package
    package/0.1.0+43.sha.43a1bb8@company

grep package  conan.lock 
        "package/0.1.0+43.sha.43a1bb8@company#c525c55123b4d0912b0fbc5e2f1f9b10%1693388200.916"

conan lock create .  --lockfile=""  --update
grep package  conan.lock 
        "package/0.1.0+43.sha.43a1bb8@company#c525c55123b4d0912b0fbc5e2f1f9b10%1693388200.916"

Version check returns as expected

In [2]: from conan.tools.scm import Version

In [3]: Version("0.1.0+44.sha.43a1bb8") > Version("0.1.0+43.sha.43a1bb8")
Out[3]: True

Best regards

[memsharded]

Hi @geir-t

Thanks for your feedback.
I think this is not a bug, but expected behavior. The --update is not an argument to update the lockfile. It is an argument for checking if the packages in the cache have more modern versions/revisions in the server. But the lockfile is actually locking. Whatever is in the lockfile will be locked, and will be resolved, irrespective of the --update argument. The argument can make sense in many scenarios, like when using --lockfile-partial because not every package is locked, or when using partial references in the lockfile, for example, locking only versions but not revisions.

The way to create a new lockfile with updated references is to do not use a previous lockfile, you can use --lockfile="" as an argument to achieve this.

[geir-t]

Thank you for the response. Yes, the test was done using --lockfile="". (even tried to delete the lock file, still same result)

[memsharded]

Oh, Ok, sorry I missed that. Let me try to reproduce with a test.

[memsharded]

You were totally right, there is a bug in the calling of the underlying API and it was not correctly processing the --update. #14643 should fix it for next 2.0.11, thanks again very much for reporting this!