[question] "recommended flow" for updating a dependency in a lockfile without pulling other dependencies?

[wuziq]

What is your question?

The documentation for evolving lockfiles says:

To be clear: manually adding with conan lock add is not necessarily a recommended flow, it is possible to automate the task with other approaches, that will be explained later.

I could be missing something obvious, but I didn't see other approaches on the page or anywhere else. (Clicking "Next" on the page just takes me to the "Dependencies conflicts" page.)

In any case, what ARE the recommended flows for updating a dependency in a lockfile "without necessarily pulling many other dependencies that could have got new versions too"?

Have you read the CONTRIBUTING guide?

• I've read the CONTRIBUTING guide

[memsharded]

Hi @wuziq

Thanks for your question.

The missing pieces could be this WIP here: conan-io/docs#3799

There could be some different approaches:

• conan lock remove the desired reference, then use --lockfile-partial to let it resolve to the latest
• Use the lockfile in the conan create of the new package, and use --lockfile-out argument to make sure the new created version is added to the lockfile, then you can use the lockfile in the downstream consumers. That is, no need to explicitly modify the lockfile in a dedicated operation, but let the operation of the creation of the new version to update the lockfile.

I'd say the second one would be more nicely explicit, because if you use the conan lock remove, you already know which package you want to update, then it is the consequence of a job building a new version or revision to be updated. Using this second flow would allow more controlled testing and building of parallel changes, for example if 2 different developers are proposing some changes for the same package simultaneously, the first approach will just take the latest revision of the 2 developers, while the second approach can control and test safely the 2 different changes concurrently.

[wuziq]

I'm not clear on the second approach.

Use the lockfile in the conan create of the new package

Let's say app requires lib_a/[some range], and I want to test app with a different version of lib_a within the range. Here, does "the lockfile" refer to the existing lockfile for app, and does "the new package" refer to the new version of lib_a?

the second approach can control and test safely the 2 different changes concurrently

Sorry if I'm totally off base, but, in this scenario, I assume the two developers have created lockfiles for their versions of lib_a, then uploaded their new versions to a remote, and then made their lockfiles available to the developers of app. Is that correct? If so, is this approach not possible with conan lock add?

[memsharded]

Let's say app requires lib_a/[some range], and I want to test app with a different version of lib_a within the range. Here, does "the lockfile" refer to the existing lockfile for app, and does "the new package" refer to the new version of lib_a?

Then there is a lockfile, that contains something like:

app/1.0#revapp1
lib_a/2.3#revliba1

Lets work with revisions (though versions will be similar). If we have 2 different developers that do simultaneous and different changes to lib_a source code, without bumping the version, then 2 different jobs are fired.

The first job does something like conan create . --lockfile=app.lock --lockfile-out=change.lock
The final change.lock will contain something like:

app/1.0#revapp1
lib_a/2.3#revliba2
lib_a/2.3#revliba1

This lockfile can now be used to build or check app, that will resolved to the locked lib_a/2.3#revliba2.

In parallel, the other job will do its own conan create . --lockfile=app.lock --lockfile-out=change.lock, resulting in another different revision:

app/1.0#revapp1
lib_a/2.3#revliba3
lib_a/2.3#revliba1

Now the job can proceed to build/check app, using this specific lockfile, that will resolve to lib_a/2.3#revliba3.

Then, the 2 concurrent CI jobs can build and test both lib_a as well as its effect on app, without any interference with each other.

If using the conan lock remove approach, both jobs might resolve to the latest lib_a/2.3#revliba3 instead.

[wuziq]

Thank you!

[memsharded]

Thanks to you for the feedback @wuziq ! There has been extended discussion in #16819 if you want to have a look, and based on it I will also add more sections to my ongoing work here conan-io/docs#3799