Deployers

Deployers are a mechanism to facilitate copying files from one folder, usually the Conan cache, to user folders. While Conan provides two built-in ones (full_deploy and direct_deploy), users can easily manage their own with conan config install.

Deployers run before generators, and they can change the target folders. For example, if the --deployer=full_deploy deployer runs before CMakeDeps, the files generated by CMakeDeps will point to the local copy in the user folder done by the full_deploy deployer, and not to the Conan cache. Multiple deployers can be specified by supplying more than one --deployer= argument, and they will be ran in order of appearance.

Deployers can be multi-configuration. Running conan install . --deployer=full_deploy repeatedly for different profiles can achieve a fully self-contained project, including all the artifacts, binaries, and build files. This project will be completely independent of Conan and no longer require it at all to build. Use the --deployer-folder argument to change the base folder output path for the deployer as desired.

Built-in deployers

full_deploy

Deploys each package folder of every dependency to your recipe’s output_folder in a subfolder tree based on:

1. The build context

2. The dependency name and version

3. The build type

4. The build arch

Then every dependency will end up in a folder such as:

[OUTPUT_FOLDER]/full_deploy/host/dep/0.1/Release/x86_64

See a full example of the usage of full_deploy deployer in Creating a Conan-agnostic deploy of dependencies for developer use.

direct_deploy

Same as full_deploy, but only processes your recipe’s direct dependencies. This deployer will output your dependencies in a tree folder such as:

[OUTPUT_FOLDER]/direct_deploy/dep

Warning

The built-in deployers are in preview. See the Conan stability section for more information.

configuration

Both the full_deploy and the direct_deploy understand when the conf tools.deployer:symlinks is set to False to disable deployers copying symlinks. This can be convenient in systems that do not support symlinks and could fail if deploying packages that contain symlinks.

Custom deployers

Custom deployers can be managed via conan config install. When looking for a specific deployer, Conan will look in these locations for the deployer in the following order:

1. Absolute paths

2. Relative to cwd

3. In the [CONAN_HOME]/extensions/deployers folder

4. As built-in deployers

Conan will look for a deploy() method to call for each installed file. The function signature of your custom deployers should be as follows:

my_custom_deployer.py

def deploy(graph, output_folder: str, **kwargs):

(Note that the arguments are passed as named parameters, so both the graph and output_folder names are mandatory)

The **kwargs is mandatory even if not used, as new arguments can be added in future Conan versions, and those would break if **kwargs is not defined.

You can access your conanfile object with graph.root.conanfile. See ConanFile.dependencies for information on how to iterate over its dependencies. Your custom deployer can now be invoked as if it were a built-in deployer using the filename in which it’s found, in this case conan install . --deployer=my_custom_deployer. Note that supplying the .py extension is optional.

See the custom deployers section for examples on how to implement your own deployers.