Migrate to external ETL regions dataset

[lucasrodes]

We want to stop generating grapher/regions/latest/regions dataset, which is meant for our Grapher database and generates this dataset in Admin which no one uses: Regions data (OWID, 2023).

Instead, we should rely on step data://external/owid_grapher/latest/regions, which should just be equivalent for use-cases like this one in owid-grapher.

Would the change in this PR suffice? Are there other instances where we rely on this dataset?

[lucasrodes]

cc. @pabloarosado since you pointed me out to this issue.

[pabloarosado]

For more context:

• ETL currently supports two solutions:
  • One is to create an export step. This automatically writes to external repositories (optionally creating a PR).
  • The other option is an external step, which is a step we know is read by an external repository.

Either of those solutions would be better than directly calling a data step from an external repos.

But from memory, I think grapher (or cloudflare-workers?) may be requiring two different regions files, so the changes proposed in this PR may not be enough. We'd need to revisit this a conversation.
NOTE: If it turns out we need two files, we could simply create two external steps.

[owidbot]

Quick links (staging server):

Site Dev	Site Preview	Admin	Wizard	Docs

Login: ssh owid@staging-site-migrate-regions-dataset

• Site-screenshots: https://github.com/owid/site-screenshots/compare/migrate-regions-dataset
• SVG tester: https://github.com/owid/owid-grapher-svgs/compare/migrate-regions-dataset

SVG tester:

Number of differences (default views): 0 ✅
Number of differences (all views): 0 ✅

Edited: 2025-02-06 11:34:10 UTC
Execution time: 1.18 seconds

[marcelgerber]

Hi! Yes this makes sense.
I've just added some lines that exclude income groups from the regions file, otherwise these would start showing up as "Your current location" in the entity selector from now.
Which is something we eventually want to do, but with a proper design for that case - see #3517.

But now this is good to go, there are no differences when run, and we indeed can get rid of the old etl step for this.

[lucasrodes]

Lovely, thanks @marcelgerber !