On 12/2/23 7:44 AM, Michał Górny wrote:
Update epytest to respect the modern NO_COLOR variable rather than Portage's old NOCOLOR. Adjust it to correctly check whether it is set
at all rather than to a specific value, to match the behavior of pytest itself.
Signed-off-by: Michał Górny <mgorny@gentoo.org>
---
eclass/python-utils-r1.eclass | 11 ++---------
1 file changed, 2 insertions(+), 9 deletions(-)
diff --git a/eclass/python-utils-r1.eclass b/eclass/python-utils-r1.eclass index 394f64a5d139..da9cb820840f 100644
--- a/eclass/python-utils-r1.eclass
+++ b/eclass/python-utils-r1.eclass
@@ -1336,15 +1336,8 @@ epytest() {
_python_check_EPYTHON
_python_check_occluded_packages
- local color
- case ${NOCOLOR} in
- true|yes)
- color=no
- ;;
- *)
- color=yes
- ;;
- esac
+ local color=yes
+ [[ ${NO_COLOR} ]] && color=no
[[ -v NO_COLOR ]]
This is processed by the pytest code:
```
if "NO_COLOR" in os.environ:
return False
```
[…] NO_COLOR environment variable that, when present and not an emptystring (regardless of its value), prevents the addition of ANSI color.
On Mon, 11 Dec 2023, Eli Schwartz wrote:
+ local color=yes
+ [[ ${NO_COLOR} ]] && color=no
[[ -v NO_COLOR ]]
On Mon, 11 Dec 2023, Eli Schwartz wrote:
"Command-line software which adds ANSI color to its output by default
should check for a NO_COLOR environment variable that, when present
and not an empty string (regardless of its value), prevents the
addition of ANSI color." -- https://no-color.org/
Again, not according to pytest itself. ;)
Given the commit message says:
"""
Adjust it to correctly check whether it is set at all rather than to a specific value, to match the behavior of pytest itself.
"""
Sysop: | Keyop |
---|---|
Location: | Huddersfield, West Yorkshire, UK |
Users: | 475 |
Nodes: | 16 (2 / 14) |
Uptime: | 16:48:52 |
Calls: | 9,487 |
Calls today: | 6 |
Files: | 13,615 |
Messages: | 6,121,086 |