Conan: deploy() method not called on transitive dependencies

[boxsmiley]

To help us debug your issue please explain:

• [x ] I've read the CONTRIBUTING guide.

• [x ] I've specified the Conan version, operating system version and any tool that can be relevant.

centos 7.5
Docker version 18.03.1-ce, build 9ee9f40

• [x ] I've explained the steps to reproduce the error or the motivation/use case of the question/suggestion.

i want to run conan install on a high-level package and have that package and all dependencies' deploy() method to be called to move it all to user space. Currently only the explicit package that is conan installed gets its deploy() method called...not the dependencies.

this is easily reproduced by clearing out the conan cache and the deployment area that is in the conanfile. then call conan install on a package with dependencies and see that the deploy method only gets called on the package that was directly referenced by conan install.

in the screenshot below, I would have liked to see the deploy(): copied XXX items for gtest and log4cxx also because newdep5 depends on them.

[boxsmiley]

i made a code change to accomplish what I was trying to do.

Here is the current implementation in manager.py about line 372.

Here is the change I made to call the deploy methods on all the dependencies.

[lasote]

Hi! this is intended behavior. The deploy() method of a package should "copy" all the needed artifacts from its dependency tree (and inner package). I'm not sure if it would make sense to do it transitively, probably depending on the usage (different dep tree) you would need to import different files.
The idea we applied with deploy() is to declare it in a "consumer" package, probably an application package, that will import all the needed assets, shared libs and rest of apps in the dependency tree.

[memsharded]

The deploy() method can copy also from transitive dependencies with the self.copy_deps(), but is the package being deployed the one that decides which files from its transitive dependencies are deployed and where.

[boxsmiley]

thank you for the quick replies. i will look into the copy_deps(). my intent was to follow D.R.Y. and not repeat myself for deployment. My target delivery does not necessarily use conan and I already encoded my dependency graph via requires. I wanted to be able to just do an arbitrary conan install and have my deployment fully populated so I can just zip it up and go. The hashes and abstractions of the conan cache make this a difficult proposition. when I used maven I had a similar problem and we did a gross find command on *.jar to create the "product".

i am open to any suggestions that you have to make this happen in a fairly elegant fashion.

[lasote]

Yes, this is a very common use case for deploy() with copy_deps(). You only need 1 deploy method declared in a "deployment" package to create the "product".

[memsharded]

Exactly, and the reason a transitive deploy() method per package doesn't make a lot of sense, is that different users want different deploys. You might want to just extract the .dll from a package and copy it in C:/system32 or the like, while other user might want to extract also the linking .lib and the headers, because want to be able to link with the deployed package. So every user defines their own deploys. You can define a specific package recipe with just a deploy() method (and the requires), for every different deploy you want to do.

[boxsmiley]

Thank you for taking time to answer my questions. I think your proposed solution will work for me. Great product. I really like what you all are doing.