[feature] Ability to specify a profile to match during conan upload

[LBHawk]

You can currently use --query QUERY during a conan upload to only upload packages matching the specified settings. This is quite useful, but it would be nice to expand on this functionality to allow you to specify a profile to match, rather than having to write out a query.

We have run into a couple of cases where it would be helpful to be able to structure package creation and upload as

conan create <package ref> -pr <profile A>
conan upload <package ref> -pr <profile A>

While this is possible by instead specifying the package ID in the upload, this is not so straightforward in an automated build. This is also possible with the existing --query flag but this is not so nice to use when needing to write out every setting in a given profile.

• I've read the CONTRIBUTING guide.

[memsharded]

Hi @LBHawk

There is a problem with this proposal. --query works over the package "properties", the settings that are stored in conaninfo.txt. This is exactly the same as a conan search (it uses ``conan search```under the hood).

The problem with a profile is that it is used to fully expand the dependency graph. It needs a "consumer" root package to be able to build the dependency graph, which might not be the one that is being created.

The way to go for this feature is to try to simplify the package ID return from the conan create. It will already be there in the json output, but maybe we could try to simplify its access.

[LBHawk]

Thanks for the explanation @memsharded.

I actually forgot about the json output when I created this issue. Is this the recommended approach? Parsing output files to pass along to other commands generally scares me, in case of some change to the output in the future :). Can we expect output files like these to follow the non-breaking policy?

[memsharded]

I actually forgot about the json output when I created this issue. Is this the recommended approach? Parsing output files to pass along to other commands generally scares me, in case of some change to the output in the future :). Can we expect output files like these to follow the non-breaking policy?

Yes, we have tried hard to not break them. I also understand the concerns of parsing json on the command line, if using any other language (python, groovy/java), it is very straightforward, for command line, maybe something like https://stedolan.github.io/jq/ (but yes, more scary), but yes, I think this will be the recommended approach right now.

Also this seems that it will be what we will try to improve, to simplify access. Another idea that we considered in the past is to make the conan create command to generate a conan.pref (#5744) file or something like that, that could be fed into conan upload, but it didn't progress. We also considered at some point the possibility to pass the full json file to conan upload. In any case it seems that the approach would be more to pass conan upload the result of previous commands, than to pass a profile.

@czoido I think this issue can be considered for the new command line design, together with the ideas of #5744

[memsharded]

For the problem of create + upload Conan 2.0.7 will implement the package-list feature in #13928, that will implement this flow (and more):

conan create app --format=json > graph.json
conan list --graph=graph.json --format=json > pkglist.json
conan upload --list=pkglist.json -r=default

This will be way more effective than trying to use profiles as inputs (that won't work, because it is not possible to map from profiles -> package_ids without a full evaluation of a dependency graph), so closing this ticket as resolved. Don't hesitate to create new tickets for any further question, thanks!