Some linter configuration files are available in the folder linter, which are executed by Github Actions and are displayed during code review as annotations, to improve recipe quality. They consume python scripts which are executed to fit CCI rules. Those scripts use astroid and pylint classes to parse Conan recipe files and manage their warnings and errors.
Pylint by itself is not able to find ConanCenterIndex rules, so astroid is used to iterate over a conanfile's content and validate CCI requirements. Pylint uses an rcfile to configure plugins, warnings and errors which should be enabled or disabled.
- Understanding the different linters
- Running the linters locally
- Pylint configuration files
- Linter Warning and Errors
- E9006 - conan-import-conanfile: ConanFile should be imported from conan
- E9005 - conan-missing-name: Every conan recipe must contain the attribute name
- E9004 - conan-package-name: Conan package names must be lower-case
- E9007 - conan-test-no-name: Do not add name attribute in test package recipes
- E9008 - conan-import-errors: Deprecated imports should be replaced by new imports
- E9009 - conan-import-error-conanexception: conans.errors is deprecated and conan.errors should be used instead
- E9010 - conan-import-error-conaninvalidconfiguration: conans.errors is deprecated and conan.errors should be used instead
- E9011 - conan-import-tools: Importing conan.tools or conan.tools.xxx.zzz.yyy should be considered as private
- E9012 - conan-attr-version: Recipe should not contain version attribute
There's a three classes of linters currently in place for ConanCenterIndex
- ConanCenter Hook - these are responsible for validating the structure of the recipes and packages.
- Pylint Linter - these are used to ensure the code quality and conventions of a recipes (i.e
conanfile.py
) - Yaml Checks - stylistic guidance and schema validation check for support files and best practices
Check the Developing Recipes for more information on each of the three linters.
- Pylint Recipe: This
rcfile
lists plugins and rules to be executed over all recipes (not test package) and validate them. - Pylint Test Package Recipe: This
rcfile
lists plugins and rules to be executed over all recipes in test package folders only:
Here is the list of current warning and errors provided by pylint, when using CCI configuration.
from conans import ConanFile
Should be replaced by:
from conan import Conanfile
The attribute name
is always expected. On the other hand, version
should not be listed.
def BazConanfile(ConanFile):
name = "baz"
The package name is always lower-case, even when the upstream uses another format
def FoobarConanfile(ConanFile):
name = "foobar"
The test package is not a recipe, thus, it should not have a name
def TestPackageConanFile(ConanFile):
name = "test_package" # Wrong!
Read v2_linter for a list of mappings of v1 to v2.
Regular imports from conans.tools
are now updated:
from conans import tools
...
tools.rmdir(os.path.join(self.package_folder, "shared"))
Should be replaced by specialized tools, prepared for Conan 2.0
from conan.tools.files import rmdir
...
rmdir(self, os.path.join(self.package_folder, "shared"))
E9009 - conan-import-error-conanexception: conans.errors is deprecated and conan.errors should be used instead
from conans.errors import ConanException
Should be replaced by:
from conan.errors import ConanException
Only the namespace conans
has been replaced by conan
.
E9010 - conan-import-error-conaninvalidconfiguration: conans.errors is deprecated and conan.errors should be used instead
from conans.errors import ConanInvalidConfiguration
Should be replaced by:
from conan.errors import ConanInvalidConfiguration
Only the namespace conans
has been replaced by conan
.
E9011 - conan-import-tools: Importing conan.tools or conan.tools.xxx.zzz.yyy should be considered as private
Documented on conanfile.tools:
It's not allowed to use tools.xxx
directly:
from conan import tools
...
tools.scm.Version(self.version)
Neither sub modules:
from conan.tools.apple.apple import is_apple_os
Only modules under conan.tools
and conan.tools.xxx
are allowed:
from conan.tools.files import rmdir
from conan.tools import scm
All recipes on CCI should be generic enough to support as many versions as possible, so enforcing a specific version as attribute will not allow to re-use the same recipe for multiple release versions.
from conan import ConanFile
class FooConanFile(ConanFile):
version = "1.0.0" # Wrong!
The package version should be passed as command argument, e.g:
conan create all/ 1.0.0@ -pr:h=default -pr:b=default
Or, if you are running Conan 2.0:
conan create all/ --version=1.0.0 -pr:h=default -pr:b=default
The only exception is when providing system
packages, which are allowed.
from conan import ConanFile
class FooConanFile(ConanFile):
version = "system" # Okay!