AssertionError: Unable to handle 'index' format version '1'
Closed this issue · 2 comments
git-afsantos commented
Just for the record. This is another issue I ran into when testing some bugs older than Jan. 2014. Full output below.
(robust) andre@andre:~/robust/rosinstall_generator_time_machine$ time_machine https://github.com/yujinrobot/kobuki/issues/257 a794de9 groovy kobuki_bumper2pc deps_a794de9.rosinstall
Switched to branch 'master'
Your branch is up-to-date with 'origin/master'.
Retrieving issue 'created_at' property for: https://github.com/yujinrobot/kobuki/issues/257
Found: 2013-05-15T07:58:23Z
Determined rosdistro commit: 9237f9305715005a8b9f206efb42916bcb2cb5d9
Going back in rosdistro's history
Switched to a new branch 'bughunt_a794de9'
Building cache ..
Traceback (most recent call last):
File "/home/andre/robust/bin/rosdistro_build_cache", line 115, in <module>
main()
File "/home/andre/robust/bin/rosdistro_build_cache", line 90, in main
ignore_errors=args.ignore_errors)
File "/home/andre/robust/lib/python3.5/site-packages/rosdistro/distribution_cache_generator.py", line 56, in generate_distribution_caches
index = get_index(index)
File "/home/andre/robust/lib/python3.5/site-packages/rosdistro/__init__.py", line 105, in get_index
return Index(data, base_url, url_query=url_parts.query)
File "/home/andre/robust/lib/python3.5/site-packages/rosdistro/index.py", line 49, in __init__
assert int(data['version']) > 1, "Unable to handle '%s' format version '%d' anymore, please update your '%s' file to version '2' or '3'" % (Index._type, int(data['version']), Index._type)
AssertionError: Unable to handle 'index' format version '1' anymore, please update your 'index' file to version '2' or '3'
gavanderhoorn commented
Thanks. I'll look into it.
This is actually the error I would expect. The one in #2 is probably related, but is a new one for me.
gavanderhoorn commented
While not actually fixed -- that would require supporting all versions of the yaml formats of ros/rosdistro
-- this particular error should not occur any more with the merge of #8: the new version of the time machine checks to make sure that the user doesn't attempt to go back before the date it currently supports.
So a known limitation, but it should not result in a user facing error message any longer.