-
Notifications
You must be signed in to change notification settings - Fork 223
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.
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
Clean up exports #2468
Comments
While we're at it, maybe we don't need to re-export everything from these packages (though I could see making an exception for Distributions.jl): Line 7 in 24d5556
And maybe we can re-export |
Finally, I think the export list should be sorted / organised by the origin package of each symbol being exported, so the DynamicPPL stuff should be grouped, etc. It kind of is already, but not totally. That will make it easier for us to know when something requires a breaking release. |
Libtask I would think wouldn't need any re-exporting, it seems like an implementation detail to me. Maybe Bijectors likewise. We probably need something from AbstractMCMC and MCMCChains, but I, too, would like to be more selective. |
Turing.jl/src/Turing.jl
Lines 80 to 84 in 24d5556
Turing re-exports the entire DynamicPPL module, as shown above. This means that any breaking change in DynamicPPL is also technically a breaking change in Turing.
However, we haven't really obeyed this at all: many breaking changes in DynamicPPL have been released as patch level bumps in Turing. This means that technically, a patch version of Turing could break any code that looks like
where
foo
was something that was changed in a minor release of DynamicPPL.'But, Penny, who would write such horrible code?' I hear you ask. Well, if nobody would do that, then there's no reason to re-export DynamicPPL ;)
The text was updated successfully, but these errors were encountered: