[question] Is there a way to create a lockfile without the revisions?

[RochaStratovan]

What is your question?

How would I create a lockfile that has the versions, but not the revisions?

When I issue the command

conan lock create foo --version 1.2.5 -u

The generated lockfile includes the version and the revision. Such as

$ cat foo/conan.lock
{
    "version": "0.5",
    "requires": [],
    "build_requires": [
        "sv_build_tools/1.0.0#099cdc101846aebb1b5f81540ac0bb40%1708467392.241"
    ],
    "python_requires": [
        "stvn_recipes/1.0.0#8f709de1bcde37e0554f926191a4bdac%1708467392.203"
    ]
}

I'd like it to just give me the version, because I want to use the latest revisions.

I know I could edit the file, but I'm wondering if there is a CLI option that I don't understand that would do what I want automatically.

Have you read the CONTRIBUTING guide?

• [X] I've read the CONTRIBUTING guide

[memsharded]

Hi @RochaStratovan

This is probably not recommended at all. The purpose of a lockfile is to provide reproducibility, and this would break it.

It seems that you are creating multiple revisions for the same version. Let's think in CI, and that some changes for a given package are being tested. These changes will create a new revision. But any other possible change that is concurrent, and then your CI builds are using one revision in the first part of the builds and a different revision at other part of the build (or like the Windows build uses one revision, and the Linux build uses another revision). This also happens for dependencies. Imagine you are doing a change in a package "A". But it happens that "A" has a dependency on "D", and "D" has also got an update by other team. It is very possible that part of the builds are done with one revision or version of D and another part of the build are done with another version or revision of D.

And this is both very complicated to understand and debug, as the failures can get unnoticed until later at runtime. The only way to protect against it is using lockfiles with locked revisions.

Also this kind of flow might break the lockfiles consistency. Because a new revision can change a requires and define a new version or range not in the lockfile, then the lockfile will fail to evaluate, or force you to use --lockfile-partial all the time, which doesn't guarantee that all dependencies are in fact locked.

Probably I don't know enough about the use case or what you are trying to achieve, but it seems like a flow not requiring lockfiles. If you don't want to use the latest version of dependencies, maybe then generate a pre-release instead? What is the purpose of using lockfiles if not achieving reproducible dependencies?

[RochaStratovan]

Hello @memsharded,

We're still struggling with trying to find a way to do branching with conan.

The latest idea was to use a remote registry for the modified elements while still using the dev registry for elements that are not part of the feature branch.

So for a simple A <- B <- C scenario where feature branch SB-129 needs to modify B and C we would:

1. Create remote artifactory registry for SB-129
2. create a lockfile for C w/o the revision identifiers
3. Pull B
4. Copy lockfile to B
5. Develop B@SB-129. Where feature branch commits deploy to registry SB-129. But A is still coming from Dev@Latest
6. Pull C along with the lockfile
7. Develop C@SB-129, using B@SB-129(latest) and A@dev(latest).

The idea was to use the "open" lockfile for development that keeps us on feature branch SB-129. The standard strict lockfiles would be part of the CI pipeline, but the "open" lockfiles would be for the development pipline.

[memsharded]

Hi @RochaStratovan

Sorry this was not followed up.

It is probably better to start the other way round:

• You had some modifications to one package or two, like B and C
• You can conan export them, capture that in a lockfile., to a secondary server repo. It doesn't even need to be a new one per branch or pull request. That will force that specific revision of B and C into any consumers
• Now to integrate down those changes in the graph, do a conan lock create over the most downstream consumers, like A, passing the lockfile you already captured. That will keep B and C locked to the revisions you want to test and will lock everything else to whatever other versions and revisions are available, if you have the main repository as the first one, it will be prioritized.
• Now you have the full lockfile for your product to build, you can start building whatever needs to be built. A conan graph build-order can help you to distribute the build if that is what you want, otherwise a --build=missing can help