compatibility with pvlib 0.7.x

pvlib 0.7 introduced two API changes that break RdTools, specifically normalization.sapm_dc_power. The easiest way forward would just be to bump the pvlib requirement to 0.7.1, but assuming we want to support both 0.6.x and 0.7.x, here are some possible workarounds:

pvlib.pvsystem.sapm_effective_irradiance

pvlib 0.6.x divides effective_irradiance by reference_irradiance (default 1000). RdTools passes in reference_irradiance=1 to keep units W/m2, but pvlib 0.7 dropped the reference_irradiance argument so this line now raises TypeError: https://github.com/NREL/rdtools/blob/development/rdtools/normalization.py#L182

• make the call with reference_irradiance=1 and if TypeError is raised, call it again without reference_irradiance
• check the pvlib version at runtime and include the argument if it is appropriate (example: https://stackoverflow.com/a/11887885/1641381).
• drop the parameter and check if all return values are < ~1.5. If so, multiply result by 1000.

pvlib.pvsystem.sapm_celltemp

The class method PVSystem.sapm_celltemp is deprecated in 0.7.0 and also had the argument names and order change. The recommended replacement is pvlib.temperature.sapm_cell (new in 0.7.0).

• Because sapm_celltemp arguments changed in 0.7.0, the code in development raises TypeError. Similar to above, one option is to try the code as-is and fall back to temperature.sapm_cell if it fails.
• Check pvlib version at runtime, dispatch appropriately.

I think I prefer the version-checking method for both cases because catching TypeError is an overly broad test. It does put a dependency on the packaging package, but it comes with setuptools so in theory should already exist anywhere RdTools is installed (I think?). Any thoughts?

[kanderso-nrel]

It doesn’t matter that much to me that TypeError is overbroad, it either works or doesn’t.

My motivating example for avoiding try/except for this kind of branching is the error message presented to the user when they misuse RdTools. Normally they’d get a (hopefully useful) error message involving the inputs that they’re misusing, but the try/except version branching method gives them some weird error about sapm_effective_irradiance() got an unexpected keyword which doesn’t help them at all. It’s true that bad user input produces an error either way, but one way can point them in the right direction and the other makes it look like RdTools has a bug.

but I agree the chances that setuptools isn’t in the target env is rare - do setup.py explicitly check for it?

Ours does! https://github.com/NREL/rdtools/blob/master/setup.py#L3-L6

but you could just read the string directly from pvlib.version and check if it starts with ‘0.7’

Maybe this is so down in the weeds that it doesn’t matter, but I was hesitant to mess with version strings directly because of things like 2.0.0-alpha.0 or 1.2.0+213.g19cf7e8. That said, version string craziness is always a suffix as far as I know so your startswith method is probably fine until pvlib 0.8 comes out 😃

[kanderso-nrel]

Let’s keep it simple; bump the requirement to 0.7.1 and if people complain, we can add backwards compatibility at that point.