internal_schema_ver_for_package_ver can return None for the current package if there's a weird code bug; while that should "never happen" IMO we should actually abort if that is detected.
shared.get_last_schema_version can also return 0 for "previous schema" if the choicefile is missing. That could be true either if the config data is from a pre-0.3.0 installation or I guess if the config data has been messed with. Rather than returning 0 it should probably return None, and the caller should abort the run ... I don't think we need to worry about dealing with pre-0.3.0 data formats. Edit: also the choicefile will be missing on first run! got to make sure we don't abort then.
Also kind of related: the docstrings for the various module init functions currently say that they are accepting str-type chaintool version, but actually now they are accepting int-type schema version, so those comments need to be changed.
internal_schema_ver_for_package_ver can return None for the current package if there's a weird code bug; while that should "never happen" IMO we should actually abort if that is detected.
shared.get_last_schema_version can also return 0 for "previous schema" if the choicefile is missing. That could be true either if the config data is from a pre-0.3.0 installation or I guess if the config data has been messed with. Rather than returning 0 it should probably return None, and the caller should abort the run ... I don't think we need to worry about dealing with pre-0.3.0 data formats. Edit: also the choicefile will be missing on first run! got to make sure we don't abort then.
Also kind of related: the docstrings for the various module init functions currently say that they are accepting str-type chaintool version, but actually now they are accepting int-type schema version, so those comments need to be changed.