rosin-project/rosinstall_generator_time_machine

AssertionError: Unable to handle 'index' format version '1'

Closed this issue · 2 comments

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'

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.

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.