Pycountry 22.1.11 new subdivision types break country importation script

The new values can’t fit in the predefined keys for the subdivision type selection.


import pycountry
for t in sorted({sub.type.lower() for sub in pycountry.subdivisions}): print(t)

for pycountry 20.7.3 and 22.1.11 will yield the different type sets with the following additions

administrative precinct
autonomous city in north africa
city municipality
decentralized regional entity
district municipality
district with special status
districts under republic administration
federal capital territory
free municipal consortium
group of islands (20 inhabited islands)
metropolitan administration
metropolitan city
metropolitan collectivity with special status
overseas collectivity
overseas collectivity with special status
pakistan administered area
regional state
rural municipality
special administrative city
special self-governing city
special self-governing province
urban community
urban municipality

and modifications

chains (of islands)					      |	chain (of islands)
federal territories					      |	federal territory
island group						      |	islands, groups of islands
overseas territorial collectivity			      |	overseas territory
popularates						      |	popularate

and many deletions.

So a debate is open on how tryton should keep up with this rather arbitrary and evolving data set.

For an immediate mitigation, freeze your pycountry installs to version 20.7

This has been already reported on our issue tracker.

A proposed solution is already there, so we are just missing somebody to work on it.

1 Like

Regarding the released 6.0 LTS, the subdivision type selection could be extended to the union of the different value sets that each pycountry version would yield.

Otherwise, the extra dependency trytond-country[data] should state to depend on pycountry==20.7.3 because pycountry does not abide by semver and any future or past release could potentially break the import script. Yet this would be quite troublesome for pip dependency resolution.

New strings can only be added to newer series to be able to translate them. So this is not a possible solution.

Pining the version will prevent updating to new data. I think it will be better to avoid the script fails (as already suggested)

I think I am missing why no translations can be backported to old releases. Is there any docs or discussion about that?

Wouldn’t that require a new choice for the type selection with a None key and its corresponding printable value translations as well?

Translation requires a database update and our policy is to not backport changes that require database update.

Probably but as it printable value is an empty string I do not think this will be a big issue.

1 Like