Export predict with 0.35

[sunxd3]

No description provided.

[codecov]

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 84.60%. Comparing base (a765af3) to head (94b68bf).
Report is 3 commits behind head on release-0.35.

Additional details and impacted files

@@              Coverage Diff              @@
##           release-0.35     #821   +/-   ##
=============================================
  Coverage         84.60%   84.60%           
=============================================
  Files                34       34           
  Lines              3832     3832           
=============================================
  Hits               3242     3242           
  Misses              590      590           

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

[mhauru]

I like the docs summary. Can/should we export predict though when MCMCChains isn't a dependency of DPPL? It feels odd to me, though I think there may be context here that I'm missing (did we recently change something else about how predict is exported from various packages?). EDIT: Never mind, I was looking at an old branch when grepping.

[sunxd3]

We moved predict from Turing.jl to DynamicPPL.

There are currently two predict in DynamicPPL. One that takes vector of VarInfo, and the other takes Chain.

I am actually not super strong-willed on exporting. It was prompted by TuringLang/Turing.jl#2497 where I just can't get predict to show up on Turing.jl's doc. So I thought we can have predict on DynamicPPL's doc and we just have a pointer in Turing.jl what points to the DynamicPPL's API page.

[yebai]

Can we mark DynamicPPL.predict as public instead? Generally, we should minimise exports from DynamicPPL and let Turing decide what to export.

Related: compintell/Mooncake.jl#477

[mhauru]

Ignore my earlier comment, I was looking at an old branch.

Yes, happy with this to be exported. @yebai, I think generally switching to public could be a good idea for a package that isn't user-facing except for power users. I wonder if we should do it in one big swoop though. Might be a bit confusing if we use public for one thing and one thing only, and everything else is still exported.

[sunxd3]

still the MCMCChainsExt version of the doc is not showing up, maybe I need to transfer the docstring back to the main package?

[coveralls]

Pull Request Test Coverage Report for Build 13553064017

Warning: This coverage report may be inaccurate.

This pull request's base commit is no longer the HEAD commit of its target branch. This means it includes changes from outside the original pull request, including, potentially, unrelated coverage changes.

• For more information on this, see Tracking coverage changes with pull request builds.
• To avoid this issue with future PRs, see these Recommended CI Configurations.
• For a quick fix, rebase this PR at GitHub. Your next report should be accurate.

Details

• 0 of 0 changed or added relevant lines in 0 files are covered.
• 25 unchanged lines in 4 files lost coverage.
• Overall coverage decreased (-12.2%) to 72.51%

---

Files with Coverage Reduction	New Missed Lines	%
src/model.jl	3	81.67%
src/simple_varinfo.jl	5	76.02%
src/varinfo.jl	6	82.17%
src/threadsafe.jl	11	57.14%

Totals
Change from base Build 13548759744:	-12.2%
Covered Lines:	2767
Relevant Lines:	3816

---

💛 - Coveralls

[penelopeysm]

still the MCMCChainsExt version of the doc is not showing up

https://discourse.julialang.org/t/display-docstring-for-extension-method-in-documentation/99720

It seems like inside the docs/make.jl file you need to write

modules = [
    DynamicPPL,
    isdefined(Base, :get_extension) ? Base.get_extension(DynamicPPL, :DynamicPPLMCMCChainsExt) : DynamicPPL.DynamicPPLMCMCChainsExt,
]

Or since we are on Julia ≥ 1.10 we can skip the check

modules = [
    DynamicPPL,
    Base.get_extension(DynamicPPL, :DynamicPPLMCMCChainsExt),
]

Edit: I did a PR based on the above: #822

[penelopeysm]

I'm just going to rebase into the 0.35 branch before merging merge this into the 0.35 branch, then we can merge that into master all at one go.

Thanks for tracking this down @sunxd3 :)