From 50ee136e9f08e3038e03c5195f9a8f5c4cd28d77 Mon Sep 17 00:00:00 2001 From: memsharded Date: Mon, 27 Jan 2025 14:20:59 +0100 Subject: [PATCH 1/3] workspace build command --- incubating.rst | 56 +++++++++++++++++++++++++++++++++++++++++++++++--- 1 file changed, 53 insertions(+), 3 deletions(-) diff --git a/incubating.rst b/incubating.rst index bedb679bf5b1..d1aae7b64c4e 100644 --- a/incubating.rst +++ b/incubating.rst @@ -53,13 +53,15 @@ Workspaces The workspaces feature can be enabled defining the environment variable ``CONAN_WORKSPACE_ENABLE=will_break_next``. The value ``will_break_next`` is used to emphasize that it will change in next releases, and this feature is for testing only, it cannot be used in production. -Once the feature is enabled, workspaces are defined by one or both ``conanws.yml`` and/or ``conanws.py`` files. -By default, any Conan command will traverse the file system from the current working directory until it finds one of those files. That will define the "root" workspace folder. +Once the feature is enabled, workspaces are defined by the ``conanws.yml`` and/or ``conanws.py`` files. +By default, any Conan command will traverse up the file system from the current working directory to the filesystem root, until it finds one of those files. That will define the "root" workspace folder. The ``conan workspace`` command allows to open, add, remove packages from the current workspace. Check the ``conan workspace -h`` help and the help of the subcommands to check their usage. Dependencies added to a workspace work as local ``editable`` dependencies. They are only resolved as ``editable`` under the current workspace, if the current directory is moved outside of it, those ``editable`` dependencies won't be used anymore. +The paths in the ``conanws`` files are intended to be relative to be relocatable if necessary, or could be committed to Git in mono-repo like projects. + The ``conanws.yml`` and ``conanws.py`` files act as a fallback, that is, by default a workspace will look for an ``editables()`` function inside the ``conanws.py`` and use it if exists. Otherwise, it will fallback to the ``editables`` definition in the ``yml`` file. A workspace could define editables dynamically for example: @@ -111,11 +113,59 @@ Likewise, the ``home_folder``, to define an optional Conan cache location for th # to the workspace root folder) return "new" + conanws_data["home_folder"] +conan workspace add/remove +++++++++++++++++++++++++++ + +Use these commands to add or remove editable packages to the current workspace. The ``conan workspace add `` folder must contain a ``conanfile.py``. + +conan workspace info +++++++++++++++++++++ + +Use this command to show information about the current workspace + +.. code-block:: bash + + $ cd myfolder + $ conan new workspace + $ conan workspace info + WARN: Workspace found + WARN: Workspace is a dev-only feature, exclusively for testing + name: myfolder + folder: /path/to/myfolder + products + app1 + editables + liba/0.1 + path: liba + libb/0.1 + path: libb + app1/0.1 + path: app1 + + +conan workspace open +++++++++++++++++++++ The new ``conan workspace open`` command implements a new concept. Those packages containing an ``scm`` information in the ``conandata.yml`` (with ``git.coordinates_to_conandata()``) can be automatically cloned and checkout inside the current workspace from their Conan recipe reference (including recipe revision). -The paths in the ``conanws`` files are intended to be relative to be relocatable if necessary, or could be committed to Git in mono-repo like projects. +conan new workspace ++++++++++++++++++++ + +The command ``conan new`` has learned a new built-in (experimental) template ``workspace`` that creates a local project with some editable packages +and a ``conanws.yml`` that represents it. It is useful for quick demos, proofs of concepts and experimentation. + + +conan workspace build ++++++++++++++++++++++ + +The command ``conan workspace build`` does the equivalent of ``conan build --build=editable``, for every ``product`` defined +in the workspace. + +Products are the "downstream" consumers, the "root" and starting node of dependency graphs. They can be defined with the ``conan workspace add --product`` +new ``--product`` argument. + + Limitations: From 1dca4c82d6a15ad4435430e9142f864733ec8bb2 Mon Sep 17 00:00:00 2001 From: James Date: Mon, 27 Jan 2025 14:49:36 +0100 Subject: [PATCH 2/3] Update incubating.rst MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Co-authored-by: Abril Rincón Blanco <5364255+AbrilRBS@users.noreply.github.com> --- incubating.rst | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/incubating.rst b/incubating.rst index d1aae7b64c4e..eecabf0c2a57 100644 --- a/incubating.rst +++ b/incubating.rst @@ -60,7 +60,7 @@ The ``conan workspace`` command allows to open, add, remove packages from the cu Dependencies added to a workspace work as local ``editable`` dependencies. They are only resolved as ``editable`` under the current workspace, if the current directory is moved outside of it, those ``editable`` dependencies won't be used anymore. -The paths in the ``conanws`` files are intended to be relative to be relocatable if necessary, or could be committed to Git in mono-repo like projects. +The paths in the ``conanws`` files are intended to be relative to be relocatable if necessary, or could be committed to Git in monorepo-like projects. The ``conanws.yml`` and ``conanws.py`` files act as a fallback, that is, by default a workspace will look for an ``editables()`` function inside the ``conanws.py`` and use it if exists. Otherwise, it will fallback to the ``editables`` definition in the ``yml`` file. From 8853ca0de2ec218a4caf6ca4e154dee33fe1d902 Mon Sep 17 00:00:00 2001 From: memsharded Date: Mon, 27 Jan 2025 14:52:38 +0100 Subject: [PATCH 3/3] review --- incubating.rst | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) diff --git a/incubating.rst b/incubating.rst index eecabf0c2a57..88d3bd407831 100644 --- a/incubating.rst +++ b/incubating.rst @@ -170,7 +170,8 @@ new ``--product`` argument. Limitations: - At the moment, the ``workspace`` feature only manages local editables packages. It doesn't create any specific meta-project, or does any orchestrated build. -- Note however, that the ``conan build . --build=editables`` can be used to do orchestrated builds accross the workspace, as it will do builds of every editable package in the workspace in the right order. - +- The ``conan workspace build`` command just iterates all products, so it might repeat the build of editables dependencies of the products. In most cases, it + will be a no-op as the projects would be already built, but might still take some time. This is pending for optimization, but that will be done later, the + important thing now is to focus on tools, UX, flows, and definitions (of things like the ``products``). For any feedback, please open new tickets in https://github.com/conan-io/conan.