Add NASA POWER to iotools

[IoannisSifnaios]

• I am familiar with the contributing guidelines
• Tests added
• Updates entries in docs/sphinx/source/reference for API changes.
• Adds description and name entries in the appropriate "what's new" file in docs/sphinx/source/whatsnew for all changes. Includes link to the GitHub Issue with :issue:`num` or this Pull Request with :pull:`num`. Includes contributor name and/or GitHub username (link with :ghuser:`user`).
• New code is fully documented. Includes numpydoc compliant docstrings, examples, and comments where necessary.
• Pull request is nearly complete and ready for detailed review.
• Maintainer: Appropriate GitHub Labels (including remote-data) and Milestone are assigned to the Pull Request and linked Issue.

This PR adds a function to get irradiance and weather data from NASA POWER. read_the_docs_link

[IoannisSifnaios]

@AdamRJensen could you give some first feedback on this?

Also, should there also be a read_nasa_power function or not?

[AdamRJensen]

Also, should there also be a read_nasa_power function or not?

I suggest just adding a get_nasa_power function for now. If there is a need for a read function, we can always add that later.

[AdamRJensen]

Initial review

[kandersolar]

A few comments, overall looks pretty good to me! Seems like the API is a little slow but not terrible: 16 seconds for a year of data.

[IoannisSifnaios]

When running pytest locally, it says that the first test is skipped. Any ideas why this is (and also, is it a problem)?

[echedey-ls]

When running pytest locally, it says that the first test is skipped. Any ideas why this is (and also, is it a problem)?

@IoannisSifnaios that's due to the flags that make the iotools tests only run when explicitly requested. The pytest command you must run is in workflows/pytest-remote-data.yml:

run: pytest tests/iotools --cov=./ --cov-report=xml --remote-data

cov parameters are just for the coverage file, you don't need em.

[IoannisSifnaios]

When running pytest locally, it says that the first test is skipped. Any ideas why this is (and also, is it a problem)?

@IoannisSifnaios that's due to the flags that make the iotools tests only run when explicitly requested. The pytest command you must run is in workflows/pytest-remote-data.yml:

run: pytest tests/iotools --cov=./ --cov-report=xml --remote-data

cov parameters are just for the coverage file, you don't need em.

I guess based on the workflow description, there should also be a remote_data label added, right?

[echedey-ls]

there should also be a remote_data label added, right?

Yup, that's right!

Edit: in fact, see it's one of the instructions (the last one) on the PR template

[echedey-ls]

Minor nitpick in Whatsnew. LGTM 💯

[echedey-ls]

Suggested change

	* Added function :py:func:`~pvlib.iotools.get_nasa_power` to retrieve data from NASA POWER.
	* Add :py:func:`pvlib.iotools.get_nasa_power` to retrieve data from NASA POWER free API.

Use imperative mood for the changelogs (latest trend in pvlib, e.g. recommended by https://common-changelog.org/)
I suggest keeping the iotools namespace visible, I think it is valuable in the context of new functionality. And stating it's a free API - for me, that guarantees it's worth considering 🤑

[AdamRJensen]

Suggested change

	parameters=DEFAULT_PARAMETERS, community='re', url=URL,
	parameters=DEFAULT_PARAMETERS, *, community='re', url=URL,

I suggest adding an asterisk which forces the remaining parameters to be specified as keywords only (not positional). The motivation is that this makes it easier to add and deprecate parameters.
@kandersolar let me hear your opinion on this.

[kandersolar]

I have been reluctant to introduce * (and /) into function signatures:

1. I have not encountered it much in role model packages like scipy (though perhaps it is there and I do not notice)
2. It doesn't seem to me that we should force a code style opinion onto users
3. It does not come with any obvious benefit to pvlib's maintenance

However, item 3 is partly rebutted by the point about deprecation, which is a good one that I had not considered.

I don't feel strongly about it. To me it seems reasonable to use * in this case, and if others think it's a good idea to start using it more in pvlib then I won't object, although I think in some cases there could be disagreement about what position in the parameters list it should take.

[AdamRJensen]

Alright let's try it out here. It's easy remove but adding it later would be a breaking change. I'm partly advocating for it because I'm toying with the idea of adding a parameter for allowing setting the index to be a time interval/period index.

[AdamRJensen]

The url should be the last parameter (standard iotools practice)