Sample: Fix PyMC posterior extraction for newer ArviZ

[Doresic]

Newer PyMC/ArviZ/xarray versions changed some objects returned by sampling and variational inference. This caused tests to fail.

This PR updates the PyMC interfaces to handle those changes:

• normalize posterior when ArviZ/xarray returns it as a DataTree group
• sample variational approximations inside the stored PyMC model context
• keep the old posterior dataset behavior unchanged

This should fix the PyMC sampling pipeline and variational inference pipeline with current dependency versions.

[codecov-commenter]

⚠️ Please install the to ensure uploads and comments are reliably processed by Codecov.

Codecov Report

❌ Patch coverage is 64.70588% with 6 lines in your changes missing coverage. Please review.
✅ Project coverage is 79.00%. Comparing base (37a58bc) to head (e8dbed2).

Files with missing lines	Patch %	Lines
pypesto/variational/pymc.py	0.00%	6 Missing ⚠️
❗ Your organization needs to install the Codecov GitHub app to enable full functionality.

❗ There is a different number of reports uploaded between BASE (37a58bc) and HEAD (e8dbed2). Click for more details.

HEAD has 1 upload less than BASE

Flag	BASE (37a58bc)	HEAD (e8dbed2)
	10	9

Additional details and impacted files

@@             Coverage Diff             @@
##           develop    #1714      +/-   ##
===========================================
- Coverage    84.27%   79.00%   -5.27%     
===========================================
  Files          164      164              
  Lines        14636    14642       +6     
===========================================
- Hits         12334    11568     -766     
- Misses        2302     3074     +772     

☔ View full report in Codecov by Sentry.
📢 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.

[dilpath]

Looks good, thanks! Is there a good reason for supporting older versions of arviz? Otherwise I would suggest to just drop support.

[Doresic]

Looks good, thanks! Is there a good reason for supporting older versions of arviz? Otherwise I would suggest to just drop support.

Yeah I was considering dropping it, but I thought it might cause a too sharp update?
Should we do some kind of deprecation update thing, warn for some time and then drop later on?

[dilpath]

Looks good, thanks! Is there a good reason for supporting older versions of arviz? Otherwise I would suggest to just drop support.

Yeah I was considering dropping it, but I thought it might cause a too sharp update? Should we do some kind of deprecation update thing, warn for some time and then drop later on?

Agreed, deprecation would be ideal. However, I don't see a strong need for it. This PR change is not user-facing and won't break their workflows directly.

[Doresic]

Looks good, thanks! Is there a good reason for supporting older versions of arviz? Otherwise I would suggest to just drop support.

Yeah I was considering dropping it, but I thought it might cause a too sharp update? Should we do some kind of deprecation update thing, warn for some time and then drop later on?

Agreed, deprecation would be ideal. However, I don't see a strong need for it. This PR change is not user-facing and won't break their workflows directly.

Hmm actually a deprecation warning is not appropriate here, since this is not pyPESTO API usage but compatibility with a dependency version. I added a small code comment noting that this branch can be simplified once we bump the minimum supported ArviZ version.

[dilpath]

Hmm actually a deprecation warning is not appropriate here, since this is not pyPESTO API usage but compatibility with a dependency version. I added a small code comment noting that this branch can be simplified once we bump the minimum supported ArviZ version.

Right, and for me it would be fine to bump the requirement already due to this PR.

[Doresic]

Hmm actually a deprecation warning is not appropriate here, since this is not pyPESTO API usage but compatibility with a dependency version. I added a small code comment noting that this branch can be simplified once we bump the minimum supported ArviZ version.

Right, and for me it would be fine to bump the requirement already due to this PR.

Makes sense, better to just do it, no reason to wait.
I'll edit the PR to include the bump too and remove support of older versions of arviz

[Doresic]

I checked this more closely and I think we cannot fully just bump here yet.

arviz>=1.1.0 requires Python >=3.12, but pyPESTO still supports Python 3.11. So if we only require arviz>=1.1.0, the pypesto[pymc] extra would stop working on Python 3.11.

That is why I kept the split for now:

• Python <3.12 gets arviz>=0.12.1,<1.0
• Python >=3.12 gets arviz>=1.1.0

I added a TODO in pyproject.toml that once we drop Python 3.11 support, we can simplify this and require only ArviZ >=1.1.0.

[Doresic]

Tests are failing, but should be solved by #1717, independent problem (pyswarm support), will merge now.