-
Notifications
You must be signed in to change notification settings - Fork 359
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[question] VirtualBuildEnv in packages that were not just built #3649
Comments
Hi @hlewin Thanks for your question. This would be mostly intended behavior. I think that in Conan 2 you might have some new functionality, for example the For deployment and runtime things, we have seen users doing a 2 step approach, first |
Yes and yes - which in my understanding means explicitly using
This is something I'll have a look at. Deciding the course of action for a transition to conan 2 is one reason of this question.
This would be no real option for the use case at hand as the question which packages and definitions are needed for a given deployment are nontrivial, ie one would have to mirror the logic of picking options and such that is done in |
Sounds it could be possible. It would be good to understand a bit more the full picture:
the semantics are that |
We deploy a package and it's (runtime) dependencies including transitive ones. Although most of those packages implement a (actually "the same") deploy method only the deploy method of the package directly deployed matters here.
Yes, clarifications would indeed be helpful in this case. Currently there are no mentions of |
That makes sense thanks for the clarification. I am going to check a little bit and experiment to see if there is some possible solution in Conan 2. Just to make sure, I understand that this doesn't work either in Conan 1, and you are mostly interested in knowing if Conan 2 has some new functionality that could help with this, is this correct? Or is it something that you managed to get it working somehow in Conan 1, and now Conan 2 is more strict in that regard and not working? |
No, I did not really get this working in conan 1. We are - for now - forcing rebuilds of packages as a workaround. I am making our stuff conan 2 compatible piece by piece and was fiddling around with If there is way to get rid of such workarounds in conan 2 this would be nice. Most of the porting to version 2 did not make any structural changes to established processes. I am just evaluating options... |
I have made this test pass in Conan 2. def test_deploy_method_tool_requires():
c = TestClient()
tool = textwrap.dedent(r"""
import os
from conan import ConanFile
from conan.tools.files import save, chdir
class Pkg(ConanFile):
name = "tool"
version = "0.1"
type = "application"
def package(self):
with chdir(self, self.package_folder):
echo = "@echo off\necho MYTOOL RUNNING!!"
save(self, "mytool.bat", echo)
save(self, "mytool.sh", echo)
os.chmod("mytool.sh", 0o777)
def package_info(self):
self.buildenv_info.prepend_path("PATH", self.package_folder)
""")
conanfile = textwrap.dedent("""
from conan import ConanFile
from conan.tools.env import VirtualBuildEnv
class Pkg(ConanFile):
name = "pkg"
version = "0.1"
tool_requires = "tool/0.1"
settings = "os"
def deploy(self):
venv = VirtualBuildEnv(self)
with venv.vars().apply():
ext = "bat" if self.settings.os == "Windows" else "sh"
self.run(f"mytool.{ext}")
""")
c.save({"tool/conanfile.py": tool,
"pkg/conanfile.py": conanfile})
c.run("create tool")
c.run("create pkg")
c.run("install --requires=pkg/0.1 -c:b tools.graph:skip_binaries=False --deployer-package=*")
assert "MYTOOL RUNNING!!" in c.out the keys are:
I think a similar approach would be feasible using the Conan 2 new external Also the approach of using a dedicated recipe that uses standard |
This does indeed look exactly like the thing I need - thank you for your efforts! I did not think about generating separate package that does the "bundling" in this scenario - although we already have a similar package in place to add implicit dependencies like compiler-specific runtime libs ( libc++ and such ) from the Conan cache to a deployment. That could indeed be extended easily to do a "dumb" deployment without gathering any implicit dependencies. That having said I would still welcome a remark in the documentation that Again - thank you for this discussion and your efforts! |
Sounds good, I'll move this ticket to the
Thanks to you for your feedback! |
What is your question?
Hello!
At least when using conan 1
VirtualBuildEnv(self)
does not seem to contain definitions from tool(or build) dependencies if the package was not built in the conan invocation.The use case here is that we are doing some stuff in the
deploy()
method like setting up RPATHs, signing binaries etc. that would need dependencies given in the build-profile as tool requirements. But when the package to be deployed was not built in the same conan invocation the tool requirements do not show up inself.dependencies
and hence they do not propagate any settings inVirtualBuildEnv
. The only things we get there are variables from the[buildenv]
section of the profile.Is this intended behaviour and is it still present in conan2? I get it is an optimization to not instantiate build-context dependencies if not necessary but the behviour right now seems strange... - like a bug to be honest.
Have you read the CONTRIBUTING guide?
The text was updated successfully, but these errors were encountered: