Bump Aesara to 2.7.5, aeppl to 0.0.32, update tests for aeppl

[maresb]

What is this PR about?

This is in preparation for a new version number of PyMC in order to delineate a point in time after the pymc-base Conda-Forge package was produced.

NOTE: This relies on the not-yet-existent v0.0.32 release of aeppl.

For Aesara and aeppl I bumped the version numbers in conda-envs/*.yml and requirements*.txt.

For PyMC I bumped the version number in pymc/__init__.py.

Checklist

• Explain important implementation details 👆
• Make sure that the pre-commit linting/style checks pass.
• Link relevant issues (preferably in nice commit messages)
• Are the changes covered by tests and docstrings?
• Fill out the short summary sections 👇

Major / Breaking Changes

• ...

Bugfixes / New features

• ...

Docs / Maintenance

• Bump dependencies Aesara to 2.7.5, aeppl to 0.0.32

[maresb]

Waiting on conda-forge/aeppl-feedstock#35 or autotick-bot

[codecov]

Codecov Report

Merging #5955 (5a0f7b1) into main (7fe5164) will decrease coverage by 0.12%.
The diff coverage is n/a.

@@            Coverage Diff             @@
##             main    #5955      +/-   ##
==========================================
- Coverage   89.54%   89.42%   -0.13%     
==========================================
  Files          73       73              
  Lines       13273    13292      +19     
==========================================
+ Hits        11885    11886       +1     
- Misses       1388     1406      +18     

Impacted Files	Coverage Δ
pymc/distributions/logprob.py	97.72% <ø> (ø)
pymc/__init__.py	68.42% <0.00%> (-31.58%)	⬇️

[maresb]

The test expects a KeyError to be raised, but the behavior was modified in aesara-devs/aeppl#151.

[twiecki]

@maresb Want to fix that here? Sounds like a simple one.

[maresb]

@twiecki I'm stuck because I'm confused what is the intention of the relevant test. I haven't ever used aeppl before, so I'm unfortunately missing context.

In the first joint_logp call, aeppl v0.0.31 raised a KeyError, but this changed via aesara-devs/aeppl#151 in v0.0.32. Now both the first and second calls to joint_logp return Sum{acc_dtype=float64}.0. Thus from the perspective of the current test, ignore_logprob is having no effect.

I was wondering if it made sense in the first case to add warn_missing_rvs=True as a kwarg, but that results in got multiple values for keyword argument here.

Any insight into what is the desired behavior here? Ping @ricardoV94

[ricardoV94]

@twiecki I'm stuck because I'm confused what is the intention of the relevant test. I haven't ever used aeppl before, so I'm unfortunately missing context.

In the first joint_logp call, aeppl v0.0.31 raised a KeyError, but this changed via aesara-devs/aeppl#151 in v0.0.32. Now both the first and second calls to joint_logp return Sum{acc_dtype=float64}.0. Thus from the perspective of the current test, ignore_logprob is having no effect.

I was wondering if it made sense in the first case to add warn_missing_rvs=True as a kwarg, but that results in got multiple values for keyword argument here.

Any insight into what is the desired behavior here? Ping @ricardoV94

We were relying on the fact that aeppl would fail with ignore_missing_rvs=False. Now we should revert it to True and test that it issues a warning in the first case but not the second.

[ricardoV94]

There's some other file, either pre-commit or mypy something that specifies aesara/aeppl versions that have to be updated as well.

Checking the last commit where these dependencies were changed should show it.

[maresb]

Good catch! Last time we actually missed bumping Aesara in this location.

[maresb]

Do I need to squash this last commit with my previous "Bump Aesara" and "Bump aeppl" commits?

[twiecki]

We can just squash-merge once we get greens.

[ricardoV94]

No need, if you don't mind we squashing all the commits when merging. Otherwise you can.

We are less strict about this here than in Aesara for example

[maresb]

Squash merge sounds great! 😅

[maresb]

All green! Ready to squash merge? 🚀

[maresb]

As soon as we get a release on PyPI I can generate the new Conda-Forge build, and then as long as there are no unexpected issues, this whole Conda recipe revamp will be complete. 😄