[feature] allow embedding of conan extension in pyinstaller package

[peakschris]

What is your suggestion?

We are building our own pyinstaller package of conan and distributing this to our users. We would also like to embed one of the conan extensions in this package, because automating install of these extensions into every users' CONAN_HOME through the organisation is difficult to do reliably.

Is there a way to do this? It is specifically the sbom extension that we want to package.

Have you read the CONTRIBUTING guide?

• I've read the CONTRIBUTING guide

[memsharded]

Hi @peakschris

Thanks for your feedback.

Couple of comments:

because automating install of these extensions into every users' CONAN_HOME through the organisation is difficult to do reliably.

Could you please clarify why? The conan config install/install-pkg has proven extremely convenient and effective way to distribute not only extensions but every configuration like remotes, global.conf, profiles, auth-plugins, etc.

It is specifically the sbom extension that we want to package.

Please check https://blog.conan.io/2025/02/05/What-is-your-code-made-of-sboms.html. The SBOM functionality is being moved to built-in, due to its importance.

Regarding the suggestion, pyinstaller wouldn't have a way to do this kind of thing, because the extensions are intended to not be part of the application itself, but fully dynamic. It would be possible to do something like adding more commands to the conan/cli/commands folder before calling pyinstaller, and that would make those commands built-in, not an extension anymore.

[peakschris]

Could you please clarify why? The conan config install/install-pkg has proven extremely convenient and effective way to distribute not only extensions but every configuration like remotes, global.conf, profiles, auth-plugins, etc.

For us, conan must work airgapped, and setting up a mirror of conan extensions only for this specific need seemed heavyweight. We were handing our other conan setup items via code in our bazel CLI. But this is interesting, perhaps I should investigate conan config install for more of our setup. If we can set up a git repo containing all our config it might simplify things.

Please check https://blog.conan.io/2025/02/05/What-is-your-code-made-of-sboms.html. The SBOM functionality is being moved to built-in, due to its importance.

This looks excellent. Could you clarify how this should be implemented and which version of conan it is available in (or if we should wait for an upcoming version)?

I guess we need to change two aspects of our current automation:

1. Our conan build pipeline currently calls conan export, conan create, conan upload on each of our dependencies and their transitive dependencies in order to mirror them to our airgapped artifactory. Do sboms automatically now get created for everything, or do we need to change something?

2. Our builds install conan packages using the bazel mechanism. We have an sbom generator for our own targets that traverses the dependency tree, ending up on packages from maven or conan. If conan, it will need to retrieve the appropriate conan-provided sbom to aggregate into our own sbom. Are these cdx json files present in the packages retrieved into the bazel workspace? Is there a standard naming convention? Or do we need to run extra conan commands to fetch them?

[memsharded]

For us, conan must work airgapped, and setting up a mirror of conan extensions only for this specific need seemed heavyweight. We were handing our other conan setup items via code in our bazel CLI. But this is interesting, perhaps I should investigate conan config install for more of our setup. If we can set up a git repo containing all our config it might simplify things.

Specially because of being airgapped, the first thing that you want to ensure is that the default center.conan.io remote is removed. Having a remotes.json there and using conan config install/install-pkg will make sure to automatically define only your remotes. The conan config install-pkg can install configuration from Conan packages, so it can be hosted in the same server repo, and it also helps with traceability and reproducibility, as it can be locked in lockfiles too, for example.

This looks excellent. Could you clarify how this should be implemented and which version of conan it is available in (or if we should wait for an upcoming version)?

It was already included in latest Conan 2.12, and we have already started to get user feedback, so already iterating and improving it for next releases.

Our conan build pipeline currently calls conan export, conan create, conan upload on each of our dependencies and their transitive dependencies in order to mirror them to our airgapped artifactory. Do sboms automatically now get created for everything, or do we need to change something?

If you for example define a hook like the one in the blog post that I shared, the sbom will be automatically created for every package, put in the package metadata folder and be uploaded to the server automatically with the conan create + conan upload commands. But you need to have the hook. The hooks can also be automatically distributed and installed with conan config install/install-pkg, but the important part is that it is not necessary to modify any recipe at all, it will work automatically. Note that this was released in last release, it is labeled as experimental, we will try to not break, but if some future fixes or improvements require to change some interface or behavior, it might happen.

The conan export command before a conan create is not necessary, as the conan create already does an export as the first step.

Our builds install conan packages using the bazel mechanism. We have an sbom generator for our own targets that traverses the dependency tree, ending up on packages from maven or conan. If conan, it will need to retrieve the appropriate conan-provided sbom to aggregate into our own sbom. Are these cdx json files present in the packages retrieved into the bazel workspace? Is there a standard naming convention? Or do we need to run extra conan commands to fetch them?

It depends on how/where are they generated. The example in the blog post put them in the package_metadata_folder, which means that by default they are not retrieved, metadata when desired should be explicitly downloaded with conan download --metadata. But it is possible to put the sboms in different places, the hook implementation decides what to do, if you want to store the sbom inside the package itself, you can change the package_metadata_folder for package_folder and that will be it, it will be inside the regular Conan package folder (which is accessible in self.dependencies["mydep"].package_folder or in the json output of the --format=json.