[question] How to bind between custom deployer and an env generator

[mikirothman]

What is your question?

Hello

We are writing custom deployer, it's job is to:

1. copy the artifacts from deps into a single bin folder (dll's / exe's).
2. copy configuration files into folders separated by the dep name (dep/config).
3. copy assets from the deps into (dep/assets).

The main purpose of the deployer is to Create an installer / docker image. another purpose is to overcome the windows 'PATH' size limitations... (which we didn't reach yet, but we assume we'll get there soon)

the issue is, when we will implement this deployer, I think we will need to reimplement the VirtualRunEnv generator as well, cause the VirtualRunEnv will still point on the conan cache instead of the newly deployment bin folder (and other possible env vars as well). is this correct ?

how does the default full_deploy deployer achieving the same effect without creating different generator ?

thanks for any assistance

Have you read the CONTRIBUTING guide?

• [ ] I've read the CONTRIBUTING guide

[memsharded]

Hi @mikirothman

Thanks for your question

the issue is, when we will implement this deployer, I think we will need to reimplement the VirtualRunEnv generator as well, cause the VirtualRunEnv will still point on the conan cache instead of the newly deployment bin folder (and other possible env vars as well). is this correct ?

I don't think so. Both VirtualBuildEnv and VirtualRunEnv uses the Environment class, which relativizes the paths. What is necessary is to let the packages they have been moved when deployed, and I think you are right this doesn't seem properly documented. The full_deploy implementation calls:

def mydeployer(...):
      for dep in dependencies:
              ...
             dep.set_deploy_folder(new_folder)

For every dependency dep deployed in its new_folder.

Please, give it a try, if it works we can move this to the docs repo to document it.

[mikirothman]

Hi

Sorry for the delay in my response, I think for my use case, the set_deploy_folder method is not enough. let's say my custom deployer sets the following package structure:

--bin --dep1 ----config ----assets --dep2 ----config ----assets --dep3 ----config ----assets

I can use set_deploy_folder('dep1') but than the PATH variable would not point on the bin folder, cause it will assume the bin folder still exists on each deployed folder, which might be ok but not for my use case. so actually, my deployer insists on separating each dependency to single bin folder (main reason to overcome Windows PATH length issues) and leave the other package hierarchy (data and configs) to an isolated folder.

[memsharded]

I can use set_deploy_folder('dep1') but than the PATH variable would not point on the bin folder, cause it will assume the bin folder still exists on each deployed folder, which might be ok but not for my use case.

I see. The set_deploy_folder() only helps if the target layout is the same as the package one. If the deployer is re-organizing things, then VirtualXXXEnv generators are not aware of that and cannot represent those new paths.

It would be the responsibility of the custom deployer to provide the consumer with the right information. I am having a look to see how this could be done. It seems that disabling VirtualBuildEnv and VirtualRunEnv and having your custom deployer instantiate an Environment() and define the conanbuild script itself directly might be the way to go, I think I'd give it a try.

[stgatilov]

I also have custom deployer which imports artefacts in different layout.

First thing I did was I looked into implementation of full_deploy... and found that it uses pretty limited approach with set_deploy_folder. So I updated cpp_info straight in my deployer. CMakeDeps + MSBuildDeps generators work fine with that. I'm not sure if this is intentionally allowed, but I'm glad that cpp_info is not locked out in deployer =)

Here is the deployer source.

[memsharded]

I'm not sure if this is intentionally allowed, but I'm glad that cpp_info is not locked out in deployer =)

It is not intended to allow modifying the cpp_info from downstream consumers. The problem is that this could have destructive effects on the data that could affect other parts. I have checked the code, and fortunately the deployers happen quite late, so it could be that nothing else is affected and you are having some luck :)

This use case might be analyzed, this might take some time, I think if it works for you at the time it is not a big risk because we don't change the cpp_info often, as the risk of breaking other users is high. So even if not documented and it could be changed, doesn't look very likely at this moment, but just be aware of the potential risk of breaking.

[mikirothman]

TNX, This approach works well.