Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Usage of configparser causes failed tests and usage on 16.04 #94

Closed
jarvisschultz opened this issue Dec 23, 2020 · 2 comments
Closed

Usage of configparser causes failed tests and usage on 16.04 #94

jarvisschultz opened this issue Dec 23, 2020 · 2 comments

Comments

@jarvisschultz
Copy link

Likely, the root cause of this bug actually has to do with packaging on of python-future and python-configparse on Ubuntu 16.04. However, I'm wondering if there's an easy way to address here. Sketch of the problem:

  • If python-configparse alone is installed, everything with catkin_lint works as expected including the passing all tests. That is good because python-configparse is a dependency of python-catkin-lint.
  • If we also have python-future installed all usage of catkin_lint breaks -- including failed tests. Example:
jarvis@jschultz:~⟫ dpkg -l |grep -e "python-\(configparser\|future\)"
ii  python-configparser                                         3.3.0r2-2                                                   all          backport of the enhanced config parser introduced in Python 3.2
ii  python-future-doc                                           0.15.2-1                                                    all          Clean single-source support for Python 3 and 2 - doc

jarvis@jschultz:~⟫ catkin_lint
catkin_lint: no path given and no package.xml in current directory
66 jarvis@jschultz:~⟫ sudo apt install python-future
Reading package lists... Done
Building dependency tree
Reading state information... Done
The following packages were automatically installed and are no longer required:
  python-bson python-bson-ext ros-kinetic-rosauth ros-kinetic-rosbridge-msgs
Use 'sudo apt autoremove' to remove them.
The following NEW packages will be installed:
  python-future
0 upgraded, 1 newly installed, 0 to remove and 4 not upgraded.
Need to get 335 kB of archives.
After this operation, 1,741 kB of additional disk space will be used.
Get:1 http://us.archive.ubuntu.com/ubuntu xenial/universe amd64 python-future all 0.15.2-1 [335 kB]
Fetched 335 kB in 0s (990 kB/s)
Selecting previously unselected package python-future.
(Reading database ... 579317 files and directories currently installed.)
Preparing to unpack .../python-future_0.15.2-1_all.deb ...
Unpacking python-future (0.15.2-1) ...
Setting up python-future (0.15.2-1) ...
update-alternatives: using /usr/bin/python2-futurize to provide /usr/bin/futurize (futurize) in auto mode
update-alternatives: using /usr/bin/python2-pasteurize to provide /usr/bin/pasteurize (pasteurize) in auto mode

jarvis@jschultz:~⟫ catkin_lint
catkin_lint: internal error: __init__() got an unexpected keyword argument 'strict'

The underlying cause of this is that when python-future is installed, running import configparse actually imports a version of the old-school ConfigParse class bundled with libpython2.7-minimal. As I said previously, I think that probably should not be happening. But it is happening and it seems like it might be tough to get traction fixing those upstream packages -- see the python-future and python-configparser bug reports (it's also not clear to me what the actual fix would be).

So the purpose of this bug report is to discuss possible options. I realize that 16.04 is pretty old at this point, but catkin_lint is released for Kinetic, and was just updated to 1.6.10 to now depend on configparser. There are other ROS packages in Kinetic that depend on python-future (e.g. ros-kinetic-rosbridge-library) so this situation really can happen. A few thoughts / ideas / questions:

  1. Glancing at the code, it seems feasible to re-write main.py to work with both old-school ConfigParser and backported configparser.ConfigParser.
  2. It could be possible to write more advanced import rules that detect when the wrong version is imported and try one-or-more of the following: attempt to import the right version, print useful warnings/errors and exit with nonzero exit code, print warnings and drop support for config files, others?
  3. This is a problem for me right now, obviously, but is this something the maintainers are open to trying to address here? Do you think we'd have better luck with fixing the underlying issue? Any ideas on how this issue could be addressed in the upstream packages?
@roehling
Copy link
Member

@mintar ran into this issue about a month ago: see #93

@jarvisschultz
Copy link
Author

Thanks for pointing me to that. I did search issues before posting this, but didn't find any (likely because the linked was switched to a discussion). I'll close this now and add to the discussion.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Development

No branches or pull requests

2 participants