[question] "full" lockfiles with prev (--lockfile-packages)

[HekyM]

What is your question?

Dear Conan team,

I was looking on changes in lockfiles done in Conan 2.x and I have few concertns about deprecated package_id + prev support (--lockfile-packages).

I see the improvements and understand the reasoning why the package_id + prev is ommited. But still not agree, that "full" lockfiles can be deprecated. Having it opt-in is OK and make sense with new design.

Use cases for multiple package revisions

Build Environment

Conan already take care about binary compatibility and important differences are covered within package_id. But for obvious reasons, it not cover every detail. It can happen that we need to do rebuild becouse of something Conan not track. It can be compiler patch version, winsdk update, etc. No software is bug free, even a small upgrade in build environment can be important in rare case.

Custom Hooks

Hooks support in Conan is powerful feature to automate custom requirements. Hook can affect binary compatibility without affecting package_id and that can even change over time with hook update. So prev-1 != prev-2. I know it's most likely bad-design and there are ways how this may be handled better (more in #18952), but it can still be best way to do it.

Example is to have post_package() hook to sign binaries (.dll, .exe). Works well until we need to change certificate, that needs to be in sync with consumer products. We can just rebuild packages with updated hook and start using them togenther with update in product. But this is the point, we relay on lockfiles in previous products versions, including ongoing release candidate, to keep using locked package revisions.

Use cases for "full" lockfiles

Information value:

Having "full" lockfiles commited within consummer product helps to track any changes made in conan. If I accept, that having multiple package revisions is model or process error, "full" lockfile is even more useful to detect issue and raise questions why that happen.

Reproducibility

If I'm using Conan with lockfiles, I would expect I can reproduce build of my product using LOCKED packages from conan from any release branch, no matter how old the release is. This is not true, if there is new revision of any package. If this state is by-design or is design-error should not be relevant. It has to be my choice, if I want EXACT state of Conan packages from time lockfile was created.

Release process and code freeze

It's common practice, that release process runs in parrallel with development. That's why we have release branches and code freeze. Without "full" lockfile support in release branch, conan not fully support code freeze because of missing package revisions. This case can be bad-design or misstake, but it can't just happen that Conan use different packages if I have them locked.

Feedback for --lockfile-packages

I try to create lockfiles with --lockfile-packages even its now internal. Format is a little bit hard to read, but I got it and looks ok.

Weird thing is that I try create lock for libcurl/8.15.0 for x86_64 and armv8 on windows. For some reason, it didn't lock strawberryperl as build_requires for x86_64, only ref. When I try to merge x86_64 + armv8 locks, it failed because of that. It works in opposit order, armv8 + x86_64, because armv8 has package_id:prev part.

Conclusion

I like the changes in lockfiles in Conan 2.X. It makes more sence to compute package_id from given settings etc, rather that pick it from lockfile with possible missmatch. But optional locking by package_id:prev map is a core feature in my opinion that has to stay.

Have you read the CONTRIBUTING guide?

• I've read the CONTRIBUTING guide