Skip to content

Deprecate modelchain.get_orientation #2495

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
wants to merge 12 commits into
base: main
Choose a base branch
from
+12 −0
Open

Deprecate modelchain.get_orientation #2495

Show file tree
Hide file tree
Changes from all commits
Commits
Show all changes
12 commits
Select commit Hold shift + click to select a range
4653d9d
enhance tests to check error message
RDaxini Jul 2, 2025
442ee6a
linting, whatsnew
RDaxini Jul 2, 2025
7b7f667
deprecate get_orientation
RDaxini Jul 3, 2025
2a7ac35
remove test
RDaxini Jul 3, 2025
8e25637
Update modelchain.rst
RDaxini Jul 3, 2025
bb3d7df
Update v0.13.1.rst
RDaxini Jul 3, 2025
e2c7fc3
Update v0.13.1.rst
RDaxini Jul 7, 2025
002d782
reinstate test
RDaxini Jul 16, 2025
aef91b7
Merge branch 'main' into modelchain_test
RDaxini Jul 18, 2025
78b71e7
update removal schedule
RDaxini Jul 18, 2025
414f8ca
Merge branch 'modelchain_test' of https://github.com/RDaxini/pvlib-py…
RDaxini Jul 18, 2025
1490b30
reinstate function in docs
RDaxini Jul 18, 2025
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
3 changes: 3 additions & 0 deletions docs/sphinx/source/whatsnew/v0.13.1.rst
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -10,6 +10,8 @@ Breaking Changes

Deprecations
~~~~~~~~~~~~
* Deprecate :py:func:`~pvlib.modelchain.get_orientation`. Removal scheduled for
``v0.14.0``. (:pull:`2691`)
Comment on lines +13 to +14
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
* Deprecate :py:func:`~pvlib.modelchain.get_orientation`. Removal scheduled for
``v0.14.0``. (:pull:`2691`)
* Deprecate :py:func:`~pvlib.modelchain.get_orientation`. (:pull:`2691`)

In case v0.14.0 turns out to be in the next few releases, I think it is better to not mention a version number.

However, I notice that generally I seem to be the only one advocating for not mentioning specific versions regarding deprecation removals. Maybe it's time to discuss and adopt an actual policy here? In the meantime, feel free to overrule me!

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

In case v0.14.0 turns out to be in the next few releases, I think it is better to not mention a version number.

Hmm that's a fair point, I confess I had not thought much about that. I think I am on board with your suggestion. If no-one objects in the next day or two, I'll commit your suggestion.

Maybe it's time to discuss and adopt an actual policy here?

+1

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I like setting a version more for us, so it does not get forgotten. I understand Kevin's point is to make it more agile.
So I propose that instead of an specific semver, we set it to removal="next version". That's agile, and concrete for users and us.

>>> import pvlib.modelchain as mc
>>> mc.get_orientation('flat')
<stdin>:1: pvlibDeprecationWarning: The pvlib.modelchain.get_orientation function was deprecated in pvlib 0.13 and will be removed in next version.
(0, 180)
>>>

And let's set the patch number too, so it's deprecated in 0.13.x and next version clearly is 0.13.(x+1).

Copy link
Member

@kandersolar kandersolar Jul 18, 2025 •
edited
Loading

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think many people (me included) would interpret "next version" to include patches, so the next version after 0.13.1 would be 0.13.2 (or 0.14.0, if there is no 0.13.2). So I don't think "next version" solves the problem in my comment above :(

I like setting a version more for us, so it does not get forgotten.

I agree, but I think the deprecation tracker is the best tool for that :)

Copy link
Member Author

@RDaxini RDaxini Jul 18, 2025 •
edited
Loading

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I had the same thought so I followed up with an off-github conversation with Echedey to clarify, I thought I might be the only one to have misunderstood 😅 I think the idea was to say something so there is a message, but without committing to something specific? @echedey-ls may be able to clarify further.

I agree, but I think the deprecation tracker is the best tool for that :)

Makes sense, so is the suggestion here just to stick with no removal statement (whatever the default is) and then make sure we all stay on top of the deprecation tracker? (Thanks for creating that @echedey-ls!) --what is the consensus?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

stick with no removal statement (whatever the default is) and then make sure we all stay on top of the deprecation tracker

This has my vote!

FYI the default is "soon":

pvlib-python/pvlib/_deprecation.py

Lines 141 to 142 in 908d3da

if removal == "":
removal = "soon"

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think many people (me included) would interpret "next version" to include patches, so the next version after 0.13.1 would be 0.13.2 (or 0.14.0, if there is no 0.13.2). So I don't think "next version" solves the problem in my comment above :(

I think that does address what I interpret the problem is, that is not declaring we are going to be agile in the removal that will happen in whatever next version is. You are right that for ensuring removals get done we have the deprecation tracker, my bad for a shitty argument.

My reasons to still support "next" do not make for a strong opinion:

  1. "soon" is not precise in the same way "next" is. And precedences of "soon" removals meant 2+ minor versions. I think we should strive for super clear declaration of intentions. And being so does not look harmful in this situation.
  2. removals in patch versions are against pvlib-flavoured semver which usually happens at minor versions. I would just heavily differentiate this edge-deprecation and removal from any other, to not mislead (new) users with the usual procedures involved in pvlib. Not all users may be aware of the deprecations tracker.

I'm in favour of removing this one in a patch version, thou. Unless anybody else objects, please go ahead with the current choice @RDaxini , I don't want to block such a small change.

* Rename parameter name ``aparent_azimuth`` to ``solar_azimuth`` in :py:func:`~pvlib.tracking.singleaxis`.
(:issue:`2479`, :pull:`2480`)

Expand Down Expand Up @@ -45,3 +47,4 @@ Maintenance
Contributors
~~~~~~~~~~~~
* Elijah Passmore (:ghuser:`eljpsm`)
* Rajiv Daxini (:ghuser:`RDaxini`)
9 changes: 9 additions & 0 deletions pvlib/modelchain.py
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -18,6 +18,8 @@
from pvlib.pvsystem import _DC_MODEL_PARAMS
from pvlib.tools import _build_kwargs

from pvlib._deprecation import deprecated

# keys that are used to detect input data and assign data to appropriate
# ModelChain attribute
# for ModelChain.weather
Expand Down Expand Up @@ -59,6 +61,13 @@
)


@deprecated(
since="0.13.1",
removal="the next version",
name="pvlib.modelchain.get_orientation",
alternative=None,
addendum=None,
)
def get_orientation(strategy, **kwargs):
"""
Determine a PV system's surface tilt and surface azimuth
Expand Down
Loading