[question] Issue with Custom Deployer - Dependencies Pointing to Cache Folder

[leviskim17]

What is your question?

Hello Conan Team,

I am experiencing an issue with a custom deployer script I have written for my project. Despite setting tools.build:download_source=True, some dependencies still point to the cache package folder instead of the expected install folder. I tried to update the generated props through scripting, but it was not easy. Is there a way to update the generated props so they point to each library's install folder, similar to how full_deploy works?

I am using the sample Code tour.

from conan.tools.files import copy
from conan.errors import ConanException
import os


def deploy(graph, output_folder, **kwargs):
    # Note the kwargs argument is mandatory to be robust against future changes.
    for name, dep in graph.root.conanfile.dependencies.items():
        if dep.folders is None or dep.folders.source_folder is None:
            raise ConanException(f"Sources missing for {name} dependency.\n"
                                  "This deployer needs the sources of every dependency present to work, either building from source, "
                                  "or by using the 'tools.build:download_source' conf.")
        copy(graph.root.conanfile, "*", dep.folders.package_folder, os.path.join(output_folder, "dependency_sources", str(dep)))

Additionally, I have another part that I would like you to check.
I have noticed an issue when using full_deploy in the provided DownloadConan.bat.txt file, where the following error occurs on specific PCs (one of jenkins PCs). Could you explain the circumstances under which this error might arise?

DownloadConan.bat.txt
Error.txt

Most relevant paths start with "E:" except of Cache folder.
CWD: E:\Jenkins\workspace\rc_feature\ReCapPro\Platform\conan
Installing Conan packages to E:\Jenkins\workspace\rc_feature\rs-thirdparty25\conan...
Props folder location: E:\Jenkins\workspace\rc_feature\ReCapPro\Platform\conan\props
Cache: C:\Users\svc_p_rcbuild.conan2

Perhaps, is there a way to get logs about full_deploy?

Thank you.

Have you read the CONTRIBUTING guide?

• I've read the CONTRIBUTING guide

[memsharded]

Hi @leviskim17

Thanks for your question.

I think there are different things here. One is

I am experiencing an issue with a custom deployer script I have written for my project. Despite setting tools.build:download_source=True, some dependencies still point to the cache package folder instead of the expected install folder. I tried to update the generated props through scripting, but it was not easy. Is there a way to update the generated props so they point to each library's install folder, similar to how full_deploy works?

The way to call making generated files relative is calling:

dep.set_deploy_folder(new_folder)

for every dep dependency that we want to relativize. I think this is not documented yet, only used internally, we might need to document it.

Other is the relocation of generated files with deployers failing with:

component.deploy_base_folder(package_folder, deploy_folder)
raise ValueError("path is on mount %r, start on mount %r" % (
ValueError: path is on mount 'E:', start on mount 'C:'
ERROR: path is on mount 'E:', start on mount 'C:'

This fails because indeed a relative path cannot be computed in Windows for different drives. This is impossible and will never work. I think that Conan might add some checks to avoid the stack trace and the error, but still generated scripts won't be able to be "relativized" and they will still point to the Conan cache, not to the deployed folder. This is a limitation of Windows relative paths, and the only possibility is to use the same drive for both the cache and the deployment.

[memsharded]

Also, note that not all generated files can be relativized. Only CMakeToolchain/CMakeDeps files and virtual environment files in Windows and MSBuildDeps provide relative paths.

[memsharded]

I have been trying to reproduce the error and the stack trace, but so far I haven't been able. It might be that some of your attempts to do the relocation might have changed the cpp_info paths unexpectedly.

[memsharded]

Any further feedback here @leviskim17 ?