[ENH] Shorten package import path from pytorch_forecasting to ptf

[harshsomankar123-tech]

Reference Issues/PRs

Fixes #2289.

What does this implement/fix? Explain your changes.

• Introduced ptf Import Wrapper: Created a lightweight ptf/ package wrapper containing a custom import redirect hook. Whenever ptf or its sub-modules (e.g., ptf.models) are imported, it dynamically redirects them to the corresponding module in pytorch_forecasting.
• Safe 1.x Release (No Folder Rename): Kept the primary codebase folder name as pytorch_forecasting/ and left all internal codebase/test imports unchanged. This avoids any breaking changes or accidental deployment breakage in the current 1.x release cycle.
• Deferred Documentation Changes: Deferred documentation and notebook changes to the 2.0 release, keeping the current 1.x documentation clean and unchanged.

What should a reviewer concentrate their feedback on?

• The implementation of the import redirect hook inside ptf/__init__.py.

Did you add any tests for the change?

Yes, added tests/test_ptf_import.py which explicitly tests the redirection hook to ensure that importing from ptf works correctly and resolves to the same classes in pytorch_forecasting.

PR checklist

• The PR title starts with either [ENH], [MNT], [DOC], or [BUG].
• Added/modified tests
• Used pre-commit hooks when committing to ensure that code is compliant with hooks.

[review-notebook-app]

Check out this pull request on 

See visual diffs & provide feedback on Jupyter Notebooks.

---

Powered by ReviewNB

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
⚠️ Please upload report for BASE (main@033169a). Learn more about missing BASE report.

Additional details and impacted files

@@           Coverage Diff           @@
##             main    #2343   +/-   ##
=======================================
  Coverage        ?   87.46%           
=======================================
  Files           ?      175           
  Lines           ?    10165           
  Branches        ?        0           
=======================================
  Hits            ?     8891           
  Misses          ?     1274           
  Partials        ?        0           

Flag	Coverage Δ
cpu	87.46% <ø> (?)
pytest	87.46% <ø> (?)

Flags with carried forward coverage won't be shown. Click here to find out more.

☔ View full report in Codecov by Harness.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

[fkiraly]

May I suggest to sequence this as following, for ensuring maximum downwards compatibility:

• instead of actually moving the folder in 1.X, do it the other way round - make ptf forward to pytorch-forecasting.
• at 2.0, switch the situation around

Documentation change right now, as planned.

This way we minimize the risk of accidental breakage, since make no major change to folders in an 1.X version.

What do you think, @phoeenniixx?

This PR can be the 2.0 PR, to be parked until the release.

[phoeenniixx]

May I suggest to sequence this as following, for ensuring maximum downwards compatibility:

• instead of actually moving the folder in 1.X, do it the other way round - make ptf forward to pytorch-forecasting.
• at 2.0, switch the situation around

Documentation change right now, as planned.

I totally agree with this. This will break a lot of code.
I have a question though:
Should we actually remove pytorch-forecasting? Is it better to still keep pytorch-forecasting forever, and ptf forwards to it. I think completely removing pytorch-forecasting can be dangerous as it might be present in the documents downstream which we dont handle? What do you think?

[harshsomankar123-tech]

@phoeenniixx @fkiraly Thank you for the review and feedback!
I agree with both of you.

Would it make sense to update this PR instead by:

• Reverting the directory rename and internal codebase imports (keeping pytorch_forecasting as the primary folder)?
• Introducing a new ptf wrapper package that forwards imports to pytorch_forecasting?
• Keeping the planned documentation updates to show ptf imports?

This would avoid the risky folder rename in the 1.x line while still introducing the new import path.

Also, regarding @phoeenniixx point, would it make sense to keep the pytorch_forecasting folder permanently, with ptf acting as a forwarding wrapper? I think its a good idea it seems like the safest long-term approach to avoid breaking downstream books, tutorials, and existing code.

WDYT????

[fkiraly]

The strategy I would suggest is as above:

• forward ptf imports to pytorch-forecasting
• start advertising ptf imports in 2.0 documentation
• at 2.0, switch the forwarding direction and change the actual folder

[harshsomankar123-tech]

Hi @fkiraly @phoeenniixx ,
I've updated this PR based on the suggested approach.

Here's what I changed:

• Reverted the folder rename and restored pytorch_forecasting as the primary package.
• Added a lightweight ptf wrapper that forwards imports to pytorch_forecasting.
• Reverted the documentation changes (README.md, CHANGELOG.md, and examples) so they stay aligned with the current 1.x release. We can update them for the 2.0 release instead.
• Added a regression test (tests/test_ptf_import.py) to verify that importing from ptf works as expected.

I'd appreciate it if you could take another look whenever you have time.
Thanks!

[phoeenniixx]

Thanks, I think as @fkiraly suggested, this will be parked till v2.0 release and will act as a release PR for that...