Windows docker image uses pyreadline causing deprecation warnings
Closed this issue · 11 comments
Digging through the docker image, here is the python dependency tree run with pipdeptree
- colcon-core [required: Any, installed: 0.6.0]
- coloredlogs [required: Any, installed: 14.0]
- humanfriendly [required: >=7.1, installed: 8.2]
- pyreadline [required: Any, installed: 2.1]
Opened issue at pyreadline. Package is likely unmaintained at this point.
pyreadline/pyreadline#65
Opened issue at humanfriendly for conditionally depending on pyreadline for specific python versions.
xolox/python-humanfriendly#44
If this isn't fixed upstream, colcon-core may need to disable coloredlogs for windows with Python >= 3.9
I created xolox/python-humanfriendly#45 to avoid the dependency for Python 3.9. If the proposed patch get merged and released we can use the new version of python-humanfriendly and manually uninstall pyreadline while still using Python 3.8 to avoid the deprecation warning.
I'm trying out patching CI as a temporary workaround: #518
I'm trying to use xolox/python-humanfriendly#45 and manually uninstall pyreadline in #518, but it looks like this is not a sufficient solution. I think either pyreadline should be removed completely as a dependency or the deprecation warning selectively silenced. I'll look into doing the latter.
I'm trying to use xolox/python-humanfriendly#45 and manually uninstall pyreadline in #518, but it looks like this is not a sufficient solution.
This will only be effective if Python 3.9 is being used. With Python 3.8 the deprecation warning is still around (since effectively the referenced PR doesn't change anything with Python < 3.9).
the deprecation warning selectively silenced.
That sounds reasonable when the Python version is < 3.9.
So, we can silence the warning by setting PYTHONWARNINGS='ignore::DeprecationWarning:pyreadline[.*]' (for example), however, this will not fix the rclpy test failures since it is passing the option -We, which has precedence over PYTHONWARNINGS...
I also looked into programmatically ignoring the warning with something like:
with warnings.catch_warnings():
warnings.filterwarnings("ignore", category=DeprecationWarning, module='pyreadline')
But it is not obvious to me where this kind of warning suppression logic should live.
Here's a couple not-so-great solutions I can think of:
- Fork pyreadline and fix the warnings.
- Fork python-humanfriendly and suppress the warnings.
1. Fork pyreadline and fix the warnings.
It seems to me that we should just do this. It's not ideal, but given that there have been no commits to that repository for 5 years, I think we'll have to do it. The question becomes how we convince pip to install our custom version, but there must be a way to do this.
Installing a fork of pyreadline fixes the deprecation warnings (and test failures in rclpy): #519