Simplify and make API credential handling more consistent
The current handling of API credentials is geared exclusively towards NLR-maintained APIs, however, there are useful components within the tooling that could be made available for the integration of other API endpoints. For example in #719, a custom implementation of the EIA API credential handling was implemented (see comments: #719 (comment)) to work around the over-specified nature of the h2integrate/resource/utilities/nlr_developer_api_keys.py. Ideally, this would be a non-resource-specific module called api_handling.py (or similar) in h2integrate/tools/ that generically specificies where and how API keys should be stored that works with NLR and other third-party tooling.
Proposed solution
Alternatives considered
The only other alternative that works currently is having each new API implementation handling whenever new functionality is introduced. This works from the #719 implementation, however it was brought up in both the prototyping and review stages that it would be nice to use the existing functionality, though it was mutually agreed upon that it's out of scope to refactor the existing API handling at the same time.
Additional context
Simplify and make API credential handling more consistent
The current handling of API credentials is geared exclusively towards NLR-maintained APIs, however, there are useful components within the tooling that could be made available for the integration of other API endpoints. For example in #719, a custom implementation of the EIA API credential handling was implemented (see comments: #719 (comment)) to work around the over-specified nature of the
h2integrate/resource/utilities/nlr_developer_api_keys.py. Ideally, this would be a non-resource-specific module calledapi_handling.py(or similar) inh2integrate/tools/that generically specificies where and how API keys should be stored that works with NLR and other third-party tooling.Proposed solution
h2integrate/resource/utilities/nlr_developer_api_keys.pytoh2integrate/tools/api_handling.py(or similar) for API handling access availability outside of the resource package.h2integrate/preprocess/eia.pyto the same generic API handling module.~/.env,~/.nlrrc,~/.h2integratercAlternatives considered
The only other alternative that works currently is having each new API implementation handling whenever new functionality is introduced. This works from the #719 implementation, however it was brought up in both the prototyping and review stages that it would be nice to use the existing functionality, though it was mutually agreed upon that it's out of scope to refactor the existing API handling at the same time.
Additional context