Distributions.jl: the probability distribution package the Julia ecosystem is built on

Five families of function over one interface

Distributions.jl is a Julia package for probability distributions and associated functions, and the README lists what it implements in five groups.

Moments, meaning the mean, the variance, skewness and kurtosis, plus entropy and other properties. Probability density and mass functions, the pdf, and their logarithm, the logpdf. Moment generating functions and characteristic functions. Sampling from a population or from a distribution. And maximum likelihood estimation.

The important thing about that list is not the breadth but the shape. These are generic functions over a type, not methods on a concrete distribution, so a distribution you implement yourself, in your own package, gets the same interface as the ones that ship with the library. That is the design decision that makes a package like this worth depending on, because a model you write later does not need a parallel set of accessor functions.

The practical consequence shows up in how you use it. You do not call NormalVariance, you call variance of a distribution, and the same call works for a fitted distribution, for a truncated one, or for one you wrote in an afternoon.

The package lives in the JuliaStats organisation, the primary language is Julia, the documentation is at JuliaStats.github.io/Distributions.jl, and the releases are frequent, with v0.25.131 published on 2026-08-20 after v0.25.130 and v0.25.129. The last push to the repository was on 2026-10-19.

Conjugate priors moved out, and that will bite someone

There is a single note in the README, and it is the kind of note that saves an afternoon.

The functionalities related to conjugate priors have been moved to the ConjugatePriors package.

That is a breaking change for anyone upgrading, and it happened without changing the major version number, because the package is still at 0.x. If your code calls the conjugate prior functions and you take a new version of Distributions, the calls fail with an undefined reference rather than a deprecation warning.

The move is the right call in isolation. Conjugate priors are a self-contained piece of statistical functionality, and a separate package lets them evolve on their own schedule.

The general lesson is about the 0.x versioning convention in the Julia ecosystem, and it applies to the whole package rather than to this one change alone. A 0.x version means no compatibility guarantee is offered, so a patch release can move a function out of the package. For a package this central, that is a real consideration for a production environment, and pinning a version with a lockfile is the practical answer.

The repository itself does not discuss this beyond the note, so the migration path is something you have to follow from the ConjugatePriors side.

Four requirements before a pull request is considered

The contributing section is the most substantive part of the README, and it is where the project's standards are written down.

The preamble says it plainly. Distributions is a central package which many rely on, and the following are required for contributions to be accepted.

First, docstrings must be added to all interface and non-trivial functions. That is the rule that keeps a generic interface discoverable, and for a package where the user discovers features by reading docstrings, it is the one that matters most.

Second, tests validating the modified behaviour, in the test folder. If new test files are added, they must be added to test/runtests.jl, which is the registration step that most contributors forget. Edge cases should be covered, and the tests should be run locally before the pull request is submitted.

Third, and this is the rule that makes the package work, Test.detect_ambiguities(Distributions) is run at the end of the tests to check for method ambiguities, and the contributor is asked to verify that their modified code did not yield any. An ambiguity in a generic function is the kind of defect that only shows up for a user with a particular type combination, and it is nearly impossible to debug from a stack trace, so the package refuses to accept one.

Fourth, corresponding modifications to the docs folder, with the documentation built locally and checked for correct display and warnings.

Building the documentation is part of the change, not a follow-up

The documentation step is specific enough to be worth following exactly, because a documentation build that emits a warning fails the requirement.

You first need to instantiate the docs project, which means selecting the docs environment in the REPL and installing its dependencies, then pointing it at the local source tree so that the documentation builds against your changes rather than against the registered package.

julia --project=docs/

pkg> instantiate
pkg> dev .

After that the build itself runs a script inside the same project environment.

julia --project=docs/ docs/make.jl

The pkg> dev . step is the one that trips people up, and the reason is worth spelling out. Without it, the docs environment resolves Distributions from the registry, so your changes are not in the documentation you just built and the check passes on stale output. With it, the docs build uses the working copy.

The same idea applies to the test suite, which the README asks you to run locally, and to the ambiguity check, which is the one step that is not optional in any sense: if your change introduces an ambiguity, the test run fails and the pull request does not get past the checks.

Where to ask, and what to bring with you

The README separates the channels carefully, and the separation is worth respecting.

For support and questions, the answer is not the issue tracker. It is the Julia Discourse forum, and for casual conversation and quick questions there are the #helpdesk and #statistics channels in the official Julia chat on Slack, with an invitation available through the Julia site. GitHub is used for the development of the package itself, which is a different thing from support.

If you have a bug, the guidance is to check that it has not already been reported on the repository issues, and if it has not, file a new issue with your version of the package. The version is obtained in the Julia REPL.

julia> ]status Distributions

That detail is not decoration. A bug in a package with a 0.x version and a rapid release cadence is often fixed by the time it is reported, and a report without a version is close to unactionable, because the maintainers cannot tell which release the reporter is on.

The report itself should be exhaustive, and should summarise the bug and provide a Minimal Working Example, what happens, and what you expected to happen. For a numerical package, a working example is also the fastest route to a fix, since it pins down the exact distribution and the exact operation.

For a pull request, the workflow is to fork the repository, clone it, make the modifications on a new branch, and not commit modifications on master, then push to the fork and open the pull request against the main repository.

Versioning, layout, and the licence to read

The release cadence is worth noting for anyone pinning. The recent tags are v0.25.131 on 2026-08-20, v0.25.130 on 2026-07-27 and v0.25.129 on 2026-06-26, so patch releases land roughly every month, and the minor version has been 0.25 for a long stretch of that numbering. The pattern is what Julia packages usually do, with the minor version rising when the interface changes and patch releases carrying fixes and small additions.

The repository layout is conventional for a Julia package. Project.toml is the package metadata, src/ holds the source, test/ the test suite with its runtests.jl entry point, docs/ the documentation source and make.jl, ext/ the package extensions, perf/ for performance benchmarks, and CITATION.bib for referencing the package.

Two of those directories are worth a second look. The ext/ directory holds Julia's package extension mechanism, which lets optional dependencies be loaded when their functionality is used rather than always, and perf/ holds the benchmarks that the performance claims in the documentation rest on.

The licence deserves attention because the metadata for this repository records it as a custom licence that GitHub cannot classify, with a LICENSE.md at the root. Many packages in the Julia ecosystem use MIT, so the fact that this one is filed differently is worth confirming by reading the file, particularly if you are redistributing it inside a product. For citation, the README points at CITATION.bib and at a Zenodo DOI badge, which is the mechanism for a persistent academic reference for a package that is archived on Zenodo.

Editorial conclusion

Distributions.jl fits a Julia team that needs distributions as first class objects rather than as functions in a statistics script, since the generic interface means a distribution you write yourself behaves like one that ships, and the maximum likelihood estimation and sampling support cover the parts of modelling people usually reach for other packages for. It does not fit a project that expects conjugate priors to be in the same package, since that functionality moved to ConjugatePriors, and it does not fit a contributor who wants a small change merged quickly, because the four contribution requirements are demanding by design. Verify three things before you depend on it: that the version you pin is one where the interfaces you use exist, given the rapid 0.25.x patch cadence, that your own methods do not introduce ambiguities, since the test suite fails on them, and that you read LICENSE.md rather than assuming the usual Julia package terms, because the repository is filed under a custom licence.

Frequently asked questions

Official sources

1. Issues
2. JuliaStats/Distributions.jl on GitHub
3. README
4. Releases