From 00e87cfba9dc3144927a214d55d1d157cbbc02a2 Mon Sep 17 00:00:00 2001 From: memsharded Date: Tue, 4 Jun 2024 15:22:53 +0200 Subject: [PATCH 1/8] vendor=True feature --- devops.rst | 1 + devops/vendoring.rst | 56 ++++++++++++++++++++++++++++++++++++++++++++ 2 files changed, 57 insertions(+) create mode 100644 devops/vendoring.rst diff --git a/devops.rst b/devops.rst index d477ffd447a9..08c2f3535307 100644 --- a/devops.rst +++ b/devops.rst @@ -18,3 +18,4 @@ If you plan to use Conan in production in your project, team, or organization, t devops/metadata devops/versioning devops/save_restore + devops/vendoring diff --git a/devops/vendoring.rst b/devops/vendoring.rst new file mode 100644 index 000000000000..72d4d1fe6068 --- /dev/null +++ b/devops/vendoring.rst @@ -0,0 +1,56 @@ +.. _devops_vendoring: + +Vendoring dependencies in Conan packages +======================================== + +.. include:: ../common/experimental_warning.inc + +From Conan 2.4 it is possible to create and use Conan packages that completely vendor their dependencies, +that is, they completely hide and isolate their dependencies from their consumers. This can be useful +in some different cases: + +- When sharing Conan packages with other organizations, that vendor (copy, embed or link) the dependencies, + so it is not necessary for hte consumers of those packages to have access to those dependencies and the + intention is that they always use the shared precompiled binaries. +- To introduce a hard decoupling between parts of a project. + +To make a package vendor its dependencies, define in its recipe the following attribute: + +.. code-block:: bash + + + class MyPkg(ConanFile): + name = "mypkg" + version = "0.1" + + vendor = True + + requires = "somedep/1.2" + + +When we have this recipe, we can create its binaries with a normal ``conan create .``. +But when we use this package as a requirement for other packages, its dependencies will be fully invisible. +The graph will not even expand the ``somedep/1.3`` requirement. This dependency doesn't even need to available +in the remotes for the consumers, it will not be checked. + +Some important notes: + +- A package that vendors its dependencies is intended to be consumed always in binary form. +- The dependencies of a vendoring package is always a fully private and isolated dependency graph, decoupled from + the rest of the dependency graph that uses this package. +- It is the responsibility of the vendoring package and its users to guarantee that vendored dependencies do not + collide. If a vendoring package vendors for example ``libssl.a`` as a static library doing a regular copy of + it in its package, and there is another package in the graph that also provides ``libssl``, there will be a + conflict that Conan cannot detect as ``libssl.a`` is vendored as an internal implementation detail of the package, + but not explicitly modeled. Mechanisms like ``provides`` can be used for this purpose, but it is the responsibility + of the recipe authors to take it into account. +- The ``package_id`` of a package that defines ``vendor=True`` is fully independent of its dependencies. The + dependencies versions will never affect the ``package_id`` of the vendoring package, so it is important + to note that the version of the vendoring package represents a full private dependency graph. +- The regular ``default_options`` or options values definitions from consumer ``conanfile.py`` recipes do not + propagate over vendoring packages, as they don't even expand their dependencies. +- If a vendoring package binary is missing and/or the user request to build such a package from sources, Conan + will fail, raising an error that it is not possible to build it. +- To allow the expansion of the private dpenedency the ``tools.graph:vendor=build`` configuration can be activated. + If that is the case, the private dependency graph of the package will be computed and expanded and the package + will be allowed to build. From 934c255b6e2f9c5ad975f4377cef81e9bdf3be4a Mon Sep 17 00:00:00 2001 From: Carlos Zoido Date: Tue, 4 Jun 2024 15:42:24 +0200 Subject: [PATCH 2/8] Update devops/vendoring.rst --- devops/vendoring.rst | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/devops/vendoring.rst b/devops/vendoring.rst index 72d4d1fe6068..bd0d810b9628 100644 --- a/devops/vendoring.rst +++ b/devops/vendoring.rst @@ -10,7 +10,7 @@ that is, they completely hide and isolate their dependencies from their consumer in some different cases: - When sharing Conan packages with other organizations, that vendor (copy, embed or link) the dependencies, - so it is not necessary for hte consumers of those packages to have access to those dependencies and the + so it is not necessary for the consumers of those packages to have access to those dependencies and the intention is that they always use the shared precompiled binaries. - To introduce a hard decoupling between parts of a project. From 8124b8f17104629c9e03e9401ac5a0f4f8b27dc5 Mon Sep 17 00:00:00 2001 From: Carlos Zoido Date: Tue, 4 Jun 2024 15:46:02 +0200 Subject: [PATCH 3/8] Update devops/vendoring.rst Co-authored-by: Daniel --- devops/vendoring.rst | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/devops/vendoring.rst b/devops/vendoring.rst index bd0d810b9628..bd0b4539c7ee 100644 --- a/devops/vendoring.rst +++ b/devops/vendoring.rst @@ -30,7 +30,7 @@ To make a package vendor its dependencies, define in its recipe the following at When we have this recipe, we can create its binaries with a normal ``conan create .``. But when we use this package as a requirement for other packages, its dependencies will be fully invisible. -The graph will not even expand the ``somedep/1.3`` requirement. This dependency doesn't even need to available +The graph will not even expand the ``somedep/1.3`` requirement. This dependency doesn't even need to be available in the remotes for the consumers, it will not be checked. Some important notes: From eb06477dfba4529fe30775f7f44909cead5b1f3f Mon Sep 17 00:00:00 2001 From: Carlos Zoido Date: Tue, 4 Jun 2024 16:20:29 +0200 Subject: [PATCH 4/8] Update devops/vendoring.rst --- devops/vendoring.rst | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/devops/vendoring.rst b/devops/vendoring.rst index bd0b4539c7ee..99135f4caf05 100644 --- a/devops/vendoring.rst +++ b/devops/vendoring.rst @@ -51,6 +51,6 @@ Some important notes: propagate over vendoring packages, as they don't even expand their dependencies. - If a vendoring package binary is missing and/or the user request to build such a package from sources, Conan will fail, raising an error that it is not possible to build it. -- To allow the expansion of the private dpenedency the ``tools.graph:vendor=build`` configuration can be activated. +- To allow the expansion of the private dependency the ``tools.graph:vendor=build`` configuration can be activated. If that is the case, the private dependency graph of the package will be computed and expanded and the package will be allowed to build. From 3880b0678f321be57a0c1aa344cd077cd35eef30 Mon Sep 17 00:00:00 2001 From: Carlos Zoido Date: Tue, 4 Jun 2024 16:20:38 +0200 Subject: [PATCH 5/8] Update devops/vendoring.rst --- devops/vendoring.rst | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/devops/vendoring.rst b/devops/vendoring.rst index 99135f4caf05..52d2f51d3c4a 100644 --- a/devops/vendoring.rst +++ b/devops/vendoring.rst @@ -30,7 +30,7 @@ To make a package vendor its dependencies, define in its recipe the following at When we have this recipe, we can create its binaries with a normal ``conan create .``. But when we use this package as a requirement for other packages, its dependencies will be fully invisible. -The graph will not even expand the ``somedep/1.3`` requirement. This dependency doesn't even need to be available +The graph will not even expand the ``somedep/1.2`` requirement. This dependency doesn't even need to be available in the remotes for the consumers, it will not be checked. Some important notes: From 0012385a2a5fd34985f759efaa6f659d51e96879 Mon Sep 17 00:00:00 2001 From: James Date: Tue, 4 Jun 2024 23:12:44 +0200 Subject: [PATCH 6/8] Update devops/vendoring.rst MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Co-authored-by: Rubén Rincón Blanco --- devops/vendoring.rst | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/devops/vendoring.rst b/devops/vendoring.rst index 52d2f51d3c4a..b39f8073bff9 100644 --- a/devops/vendoring.rst +++ b/devops/vendoring.rst @@ -9,7 +9,7 @@ From Conan 2.4 it is possible to create and use Conan packages that completely v that is, they completely hide and isolate their dependencies from their consumers. This can be useful in some different cases: -- When sharing Conan packages with other organizations, that vendor (copy, embed or link) the dependencies, +- When sharing Conan packages with other organizations which vendor (copy, embed or link) the dependencies, so it is not necessary for the consumers of those packages to have access to those dependencies and the intention is that they always use the shared precompiled binaries. - To introduce a hard decoupling between parts of a project. From 0da383cdc3aaa440b004f40ac48db50ed5c3d175 Mon Sep 17 00:00:00 2001 From: James Date: Tue, 4 Jun 2024 23:12:52 +0200 Subject: [PATCH 7/8] Update devops/vendoring.rst MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Co-authored-by: Rubén Rincón Blanco --- devops/vendoring.rst | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/devops/vendoring.rst b/devops/vendoring.rst index b39f8073bff9..91fad0d375cd 100644 --- a/devops/vendoring.rst +++ b/devops/vendoring.rst @@ -10,7 +10,7 @@ that is, they completely hide and isolate their dependencies from their consumer in some different cases: - When sharing Conan packages with other organizations which vendor (copy, embed or link) the dependencies, - so it is not necessary for the consumers of those packages to have access to those dependencies and the + so it is not necessary for the consumers of their packages to have access to those dependencies and the intention is that they always use the shared precompiled binaries. - To introduce a hard decoupling between parts of a project. From 9515f9e6be32c06e3acd67ec113544dd1e8107fc Mon Sep 17 00:00:00 2001 From: James Date: Tue, 4 Jun 2024 23:12:59 +0200 Subject: [PATCH 8/8] Update devops/vendoring.rst MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Co-authored-by: Rubén Rincón Blanco --- devops/vendoring.rst | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/devops/vendoring.rst b/devops/vendoring.rst index 91fad0d375cd..3a0f2abc2d26 100644 --- a/devops/vendoring.rst +++ b/devops/vendoring.rst @@ -36,7 +36,7 @@ in the remotes for the consumers, it will not be checked. Some important notes: - A package that vendors its dependencies is intended to be consumed always in binary form. -- The dependencies of a vendoring package is always a fully private and isolated dependency graph, decoupled from +- The dependencies of a vendoring package always form a fully private and isolated dependency graph, decoupled from the rest of the dependency graph that uses this package. - It is the responsibility of the vendoring package and its users to guarantee that vendored dependencies do not collide. If a vendoring package vendors for example ``libssl.a`` as a static library doing a regular copy of