The error message is currently extremely unhelpful:
Traceback (most recent call last):
File "kart_cli.py", line 4, in <module>
File "kart\cli.py", line 334, in entrypoint
File "lib\site-packages\click\core.py", line 829, in __call__
File "lib\site-packages\click\core.py", line 782, in main
File "kart\cli.py", line 157, in invoke
File "lib\site-packages\click\core.py", line 1259, in invoke
File "lib\site-packages\click\core.py", line 1066, in invoke
File "lib\site-packages\click\core.py", line 610, in invoke
File "lib\site-packages\click\decorators.py", line 21, in new_func
File "kart\init.py", line 355, in import_
File "kart\fast_import.py", line 349, in fast_import_tables
File "kart\fast_import.py", line 532, in _import_single_source
File "kart\fast_import.py", line 549, in write_blobs_to_stream
File "kart\fast_import.py", line 543, in write_blob_to_stream
TypeError: a bytes-like object is required, not 'list'
We only support one piece of attached metadata XML, whereas the GPKG spec allows for arbitrarily many. Trying to edit and commit a second XML attachment has a slightly better behaviour - firstly it has a better error message:
Sorry, committing more than one XML metadata file is not supported
And secondly, it's slightly less likely to happen - it's much more likely that a user will try to import an existing GPKG from some other system that happens to have multiple XML attachments than that they will edit the one in their working copy in this way, and if they do, they are more likely to be able to undo what they have done (if all else fails, by running kart reset or similar).
In the GPKGs I have seen, one of the XML attachments is often junk anyway. For instance, in the following example:
In this example, the first XML file happens not to contain any useful information, and the second XML file is just a wrapped-and-escaped version of the first XML file that needs extra parsing. The junkier XML file is slightly longer in this case, so we can't use assume that "longer" means "more informative" if we develop a heuristic to decide which XML gets to stay. We can probably detect the case where >90% of an XML file is just the same as the other XML file and the remainder is just boilerplate.
The error message is currently extremely unhelpful:
We only support one piece of attached metadata XML, whereas the GPKG spec allows for arbitrarily many. Trying to edit and commit a second XML attachment has a slightly better behaviour - firstly it has a better error message:
Sorry, committing more than one XML metadata file is not supported
And secondly, it's slightly less likely to happen - it's much more likely that a user will try to import an existing GPKG from some other system that happens to have multiple XML attachments than that they will edit the one in their working copy in this way, and if they do, they are more likely to be able to undo what they have done (if all else fails, by runningkart reset
or similar).In the GPKGs I have seen, one of the XML attachments is often junk anyway. For instance, in the following example:
First XML attachment:
Second XML attachment
In this example, the first XML file happens not to contain any useful information, and the second XML file is just a wrapped-and-escaped version of the first XML file that needs extra parsing. The junkier XML file is slightly longer in this case, so we can't use assume that "longer" means "more informative" if we develop a heuristic to decide which XML gets to stay. We can probably detect the case where >90% of an XML file is just the same as the other XML file and the remainder is just boilerplate.