After a long and awaited period, here we have the new Conan 1.8 release. It comes packed of new features and fixes and some great contributions from the community. Let’s go through some of the highlights shipped in this release.

Plugins system

Many people were asking for a way of customizing the Conan behavior to suit their needs in order to perform tasks after some actions such as installation of new packages, uploads to a server… We thought that the best approach for this would be to have a plugin feature in the Conan client, so this is what we have come up with.

Plugins are python files with some pre and post functions that receive information through parameters and are executed right before and after an action executed by Conan. Those actions are normally self-described by their name.

Here you can see a simple example of a plugin:

example_plugin.py

def pre_export(output, conanfile, conanfile_path, reference, **kwargs): # Check basic meta-data for field in ["url", "license", "description"]: field_value = getattr(conanfile, field, None) if not field_value: output.warn("Conanfile doesn't have '%s'. " "It is recommended to add it as an attribute" % field)

Plugins can have many functions and do different things in each of them. They might also have private functions or imposts from pip installed modules or relative ones.

Plugins are stored under the ~/.conan/plugins directory that can be activated on demand using conan config set and conan config rm .

There are still some things to define regarding plugins, such as the way they are installed, how they can be managed or linked to a recipe, include new functions in the future or even change current functions signature… This is why this feature is also released as experimental and will require more testing from the community. Feel free to report any issue or improvement in the Conan issue tracker using [PLUGINS] in the title.

There is also a new repository conan-io/plugins where we will develop the official plugins and manage suggestions for new ones in its own issue tracker.

SVN support for SCM

As said in previous releases, the SCM feature keeps improving and finally we have support for SVN.

There has been a huge interaction with the community with more than 80 comments and reviews to develop this new feature.

Here you can see that it can be transparently used the same way it was done for git:

from conans import ConanFile, tools class ConanLib(ConanFile): name = "lib" version = "0.1" scm = { "type": "svn", "url": "auto", "revision": "auto", "subfolder": "onesubfolder" }

There is also a new SVN tool wrapper that can be used inside your recipes for any purpose you want.

Keep in mind that the this feature is still experimental as other SCM types might be added eventually that can change the interface. However, we encourage SVN users to try this feature and report new issues or suggest improvements using [SVN] in the issue title.

New conventions for recipes

Protected ConanFile members

We have seen a great evolution of recipes being created and with the development of new features we think there is a need for a naming convention for the ConanFile attributes and methods to avoid any future collision.

From now on, we encourage users to use protected members in their recipes in case they want to use custom attributes:

class MyConanFile(ConanFile): name = "myconan" version = "1.0.0" _custom_attribute = "some_value" # user protected attribute def _custom_method(self): self.output.info(_custom_attribute)

A note has been included in the reference section to make users aware of this new convention.

Raising ConanInvalidConfiguration

There were some points in the Conan documentation where we encouraged to raise exceptions in configure() for configurations not supported in a library.

We have introduced a special exception called ConanInvalidConfiguration for this purpose that has different treatment on the return codes of the Conan client. This way exceptions of this type could be interpreted as a different error by tools like ConanPackageTools (WIP).

Here you can see an example:

from conans import ConanFile from conans.errors import ConanInvalidConfiguration class MyConan(ConanFile): name = "myconan" version = "0.1.3" settings = "os", "compiler", "arch", "build_type" def configure(self): if self.settings.os != "Windows": raise ConanInvalidConfiguration("Library only supports Windows")

Default options as a dictionary

The syntax for default options and its inferred types have always been tricky, so we have done some work to document the behavior of the option values comparison.

There is still room for improvement but is not easy to come up with a solution without breaking existing recipes. So, in order to clear the path for future development, the recommended way to declare default options is using a dictionary in conanfile.py.

class MyPkg(ConanFile): ... requires = "OtherPkg/0.1@user/channel" options = {"shared": [True, False], "option1": ["value1", "value2"], "option2": "ANY"} default_options = {"shared": True, "option1": "value1", "option2": 42, "OtherPkg:shared": True}

Build helpers with fixed installation directories

Following the issues reported from some users using SUSE and similar Linux distributions, we realized that the installation directories in the AutoToolsBuildEnvironment build helper was dependent on the platform, mainly using lib64 folder instead of lib folder.

This was breaking recipes rebuilt from sources, as the default library directory declared in self.cpp_info.libdirs for consumers is always lib.

The build helpers can’t generate a different directory structure depending on where is it executed, so we have fixed these output directories to the most common default ones for both CMake (see installation definitions) and AutoTools (see configure()) build helpers. There is also a flag use_default_install_dirs in AutoToolsBuildEnvironment to skip this behavior.

You will find a warning regarding this change in the AutoTools reference section with a clear explanation of the issue.

New generator: B2

This release brings a new generator for B2, also known as Boost Build. This generator comes with full-fledged features such as the use of subprojects and targets. It enhances the capabilities and deprecates the boost-build generator.

You have more information about it in the documentation reference: https://docs.conan.io/en/latest/reference/generators/b2.html

There are new tools and improvements available in this release too:

tools.replace_path_in_file() : New tool to replace a path in a file with another string. In Windows, it will match the path even if the casing and the path separator doesn’t match.

tools.collect_libs() now searches for libraries in self.cpp_info.libdirs .

tools.vcvars() has been enhanced to avoid hitting issues with max size of environment variables and it can also be used with clang-cl .

Finally, there has been some changes in the output:

Now, every time a conan install is issued, the configuration of the profile is printed in the output. Note that this configuration resembles the profile used for the installation and not strictly the final values applied to the package. $ conan install . Configuration: [settings] os=Windows os_build=Windows arch=x86_64 arch_build=x86_64 compiler=Visual Studio compiler.version=15 build_type=Release [options] [build_requires] [env] PROJECT: Installing /home/user/repos/conan-box2d/conanfile.py ...

Following the roadmap of deprecating Python 2, there is a new warning for Python 2 users recommending the migration to Python 3. $ conan create . conan/stable Python 2 will soon be deprecated. It is strongly recommended to use Python 3 with Conan: https://docs.conan.io/en/latest/installation.html#python-2-deprecation-notice Exporting package recipe box2d/2.3.1@conan/stable export: Copied 1 '.txt' file: CMakeLists.txt ...

If you want to know more about the changes in this release, check the full list of features and fixes in the changelog (it includes links to the related Pull Request) and don’t forget to update!