ImportError: cannot import name 'render_group' from 'rich.console'

[shotarok]

Summary

• ansible-lint failed with the following errors on a GitHub Action job

  File "/opt/hostedtoolcache/Python/3.10.1/x64/lib/python3.10/site-packages/ansiblelint/generate_docs.py", line 6, in <module>
    from rich.console import render_group
ImportError: cannot import name 'render_group' from 'rich.console' (/opt/hostedtoolcache/Python/3.10.1/x64/lib/python3.10/site-packages/rich/console.py)

• The rich (v11.0.0) seems to have a breaking change. rich/CHANGELOG.md | 11.0.0 - 2022-01-09 says

breaking Deprecated rich.console.RenderGroup, now named rich.console.Group

• We may want to specify rich>=9.5.1,<11.0.0 on setup.cfg instead of rich>=9.5.1.

Issue Type

• Bug Report

Ansible and Ansible Lint details

runner@fv-az121-779:~/work/macos-provisioning/macos-provisioning$ ansible --version
ansible [core 2.11.7] 
  config file = None
  configured module search path = ['/home/runner/.ansible/plugins/modules', '/usr/share/ansible/plugins/modules']
  ansible python module location = /opt/hostedtoolcache/Python/3.10.1/x64/lib/python3.10/site-packages/ansible
  ansible collection location = /home/runner/.ansible/collections:/usr/share/ansible/collections
  executable location = /opt/hostedtoolcache/Python/3.10.1/x64/bin/ansible
  python version = 3.10.1 (main, Dec 14 2021, 13:12:05) [GCC 9.3.0]
  jinja version = 3.0.3
  libyaml = True
runner@fv-az121-779:~/work/macos-provisioning/macos-provisioning$ ansible-lint --version
ansible-lint 5.2.1 using ansible 2.11.7

• ansible installation method: one of source, pip, OS package
• ansible-lint installation method: one of source, pip, OS package

OS / ENVIRONMENT

• Github Action MacOS Runner. Here is the workflow manifest: https://github.com/shotarok/macos-provisioning/blob/main/.github/workflows/lint.yml.

STEPS TO REPRODUCE

• Please take a look at https://github.com/shotarok/macos-provisioning/blob/main/.github/workflows/lint.yml.

Desired Behaviour

• ansible-lint can run without errors

Actual Behaviour

• ansible-lint failed with the errors. The following link has the errors: a GitHub Action job.

[ssbarnea]

Instead of adding the ceiling I would prefer to add support for that version, if not too hard.

[Asya-kawai]

I also encountered this error.

Python version:

python -V
Python 3.8.0

Ansible-lint version:

ansible-lint 5.3.1 using ansible 2.12.1

ansible-lint
Traceback (most recent call last):
  File "/home/toshiki/env/bin/ansible-lint", line 8, in <module>
    sys.exit(_run_cli_entrypoint())
  File "/home/toshiki/env/lib/python3.8/site-packages/ansiblelint/__main__.py", line 310, in _run_cli_entrypoint
    sys.exit(main(sys.argv))
  File "/home/toshiki/env/lib/python3.8/site-packages/ansiblelint/__main__.py", line 214, in main
    from ansiblelint.generate_docs import rules_as_rich, rules_as_rst, rules_as_str
  File "/home/toshiki/env/lib/python3.8/site-packages/ansiblelint/generate_docs.py", line 6, in <module>
    from rich.console import render_group
ImportError: cannot import name 'render_group' from 'rich.console' (/home/toshiki/env/lib/python3.8/site-packages/rich/console.py)

The reason of this error can be found at #1795 (comment).

• The rich (v11.0.0) seems to have a breaking change. rich/CHANGELOG.md | 11.0.0 - 2022-01-09 says

breaking Deprecated rich.console.RenderGroup, now named rich.console.Group

We can fix this error occured https://github.com/ansible-community/ansible-lint/blob/main/src/ansiblelint/generate_docs.py#L6 as below to avoid when use The rich v11.0.0.

- from rich.console import render_group
+ from rich.console import group as render_group

or PR: #1796.

I hope that this response will be done as soon as possible.

[bitnik]

@ssbarnea when would you make a new relase including this bugfix?

[ssbarnea]

I will made one today. I am working on addressing few more bits before tagging it.

[jantari]

Just had a pipeline finish successfully, fix appears to be live with ansible_lint-5.3.2

Thank you everyone for the fast response ❤️

[jedla01]

This affects 4.3.7 too on Python 3.8.12

Collecting ansible-lint==4.3.7
  Downloading ansible_lint-4.3.7-py2.py3-none-any.whl (79 kB)

  File "/opt/hostedtoolcache/Python/3.8.12/x64/bin/ansible-lint", line 5, in <module>
    from ansiblelint.__main__ import main
  File "/opt/hostedtoolcache/Python/3.8.12/x64/lib/python3.8/site-packages/ansiblelint/__main__.py", line 37, in <module>
    from ansiblelint.generate_docs import rules_as_rich, rules_as_rst
  File "/opt/hostedtoolcache/Python/3.8.12/x64/lib/python3.8/site-packages/ansiblelint/generate_docs.py", line 6, in <module>
    from rich.console import render_group
ImportError: cannot import name 'render_group' from 'rich.console' (/opt/hostedtoolcache/Python/3.8.12/x64/lib/python3.8/site-packages/rich/console.py)```

[BugBuster1701]

I have the problem only with ansible-lint 4.3.7 with rich 11.0.0.
My hotfix for Ansible-lint 4.3.7 is, install "rich" in Version <11.0.0. (rich-10.16.2)
pip install 'rich>=10.0.0,<11.0.0'

[kustodian]

@ssbarnea what's the reasoning behind not caping rich (and other libs) to the latest major versions currently available? I understand your fix to make it work with rich 11.0 and older, but tomorrow rich in version 12 might introduce a new breaking change that could break ansible-lint again.

Wouldn't it be safer to set rich>=9.5.1,<12.0.0 and increase the max version in a controllable way when the devs of the ansible-lint project decide?

[ssbarnea]

To cap or not to cap - that is effectively a gamble. So far we had only one case where rich broke us, even if it has several major versions bumps since we started using it. If 12 will break us I will add the cap, now I just a one off.

The downside of a cap is that is adding some kind of time-bomb, as it would prevent user from installing the tool in the future just because of the metadata. Imagine that two years from now, rich is version 20 and other projects require that newer version. You will not be able to install current version of linter with it, even if the code itself may work, just because that cap.

This is why my take regarding capping is: avoid them unless the projects involved have a bad track of breaking you. Add capping when you know that newer version will break you (basically that can be done by testing with pre-releases or git master branches of involved projects).

Note that might is not will. But adding a cap assures that user will not be able to install your project with newer versions of the capped dependency. That problem is that they may want to do so and I do not want to have to do a new release or even a backport to remove that cap. I already had to so it for many projects.

Also keep in mind that you could make use of our constraints.txt file if you want capped versions. Take a look at https://github.com/ansible-community/ansible-lint/blob/v5.3.2/constraints.txt

[batazor]

I'm still getting this error is there any news?