This is to continue the discussion @tlestang started with PR #43
From my comments there:
I see two different use cases here:
We or other contributors will want to add other CI APIs (e.g. for other countries), and we ideally want to make them part of CATS so that these new APIs are available to the whole community. In this case, it would be good to have all the URL/parsing codes in the same place and api_inferface is a good place for that (it also makes it easier to add things by copy-pasting). And in terms of how much hassle it is to add it, it's equivalent now and with the new code (api_interface needs to be modified either way, and current code requires messing with init.py as well), but the existing code doesn't allow user to easily pick an API, this is what the new argument --api-carbonintensity introduces.
Second use case is if users want to pass their own API wrapper directly to CATS without having to modify the code. And in this case I agree, it would be good to make it possible in an easier way. But how would that work in practice? It would be good to have an idea of how the user would do it if we want to implement it.
This issue is to discuss whether we want to implement (2) and how it would work in practice from the user's point of view.
This is to continue the discussion @tlestang started with PR #43
From my comments there:
This issue is to discuss whether we want to implement (2) and how it would work in practice from the user's point of view.