Suggestion: deprecate functions duplicated from pvlib-python

[RDaxini]

Is your feature request related to a problem? Please describe.
There appear to be many functions that are copied directly from one version or another of pvlib-python. For example, pvdeg.temperature.temperature, pvdeg.spectral.poa_irradiance, etc.

Describe the solution you'd like
What is the motivation for this? I could be missing something.
On the surface, it seems unnecessary. Where we need to use pvlib functions internally within pvdeg, I think it would be more efficient just to use the pvlib functions directly instead of duplicating them publicly and then using them. The one reason I could think of is in case we want to pin some pvdeg functionality to a specific version of a pvlib function, but I don't think that is the case(?)
I also don't see the benefit in reproducing pvlib documentation for pvlib functions that are copied over. This could be confusing for users, and itincreases the maintenance burden for us to keep it up to date with pvlib's existing documentation.

I propose deprecating in v0.6.0 or v0.6.1, and removing in the next major version release.

Describe alternatives you've considered

Additional context

[tobin-ford]

@RDaxini here are my thoughts. This probably warrants a longer discussion about the temperature implementation

temperature.temperature

Temperature wraps many of the PVLib temperature functions into one function. Previously, we had a temperature function that always used the pvlib sapm implementation. This is bad because we have to update the function to track pvlib additions to temperature functions.

I introduced this behavior for Scenario so the class could reference a general temperature object and pass in all of the possible parameters for a given model at runtime to allow for many models to be used at the same time. The pvdeg.temperature.temperature function also does preprocessing including calculating wind_speed_factor and poa_irradiance. This is the main point where it diverges from the original pvlib implementations.

https://github.com/NREL/PVDegradationTools/blob/fd0dd624ac072554749b9769ba0ffcafb9f87f20/pvdeg/temperature.py#L368C1-L399C1

There is probably a better way to wrap all pvlib temperature functions to be used in Scenarios and my original implementation is full of code smell.

We could instead use the pvlib namespace to pass the function object as provided, like the following.

scenario_temperature_wrapper(
    temp_model=pvlib.temperature.sapm_cell,
    ....
)

Or some combination approach with the name mapping similar to what exists currently.

Let me know what you think about this, I'm happy to fix my mess with the temperature functions.

spectral.poa_irradiance

This function also provides preprocessing before making a call to the pvlib implementation. This implementation has been around for a while and I'd consider it a major breaking change. I'm not sure what we can/should change about this function.

https://github.com/NREL/PVDegradationTools/blob/fd0dd624ac072554749b9769ba0ffcafb9f87f20/pvdeg/spectral.py#L102C1-L123C56

Other thoughts

• +1 on avoiding duplicating pvlib source and documentation, I agree that it is confusing.
• We could add a private wrapper function to scenario to keep the current temperature behavior, or just change the temperature model behavior. If the implementation is changed, users would likely need to provide more specific inputs to the temperature models for each object in the scenario running pipeline.