DALEX packs two packages into one repository and gives them two version lines
moDel Agnostic Language for Exploration and eXplanation
At a glance
- What is it?
- The model explanation package for R and Python shares a repository whose root is the R package, whose release tags follow three different conventions, and whose R how-to guides are served from a third-party GitHub content mirror.
- Who is it for?
- DALEX is worth reading the source layout of before adopting, because the repository is not the unit of release. The R package is the one whose files sit at the root and whose CRAN badge leads the page; the Python package lives under `python/` and carries its own tag prefix.
- Can I use it commercially?
- Yes, with conditions. GPL-3.0 is a copyleft licence: if you distribute software that includes it, you must release that software's source code under the same licence. Running it internally without distributing it does not trigger that obligation.
- Is it still maintained?
- Yes. The repository last received commits 82 days ago.
- What is it written in?
- Mainly Python, according to GitHub's language statistics.
Answers come from the project's GitHub data, last synced on October 5, 2026, and from our analysis. They are not legal advice.
Editorial analysis
Two packages share one repository, and the root belongs to the R one
The repository is described as moDel Agnostic Language for Exploration and eXplanation, and its primary language is recorded as Python. The file tree says otherwise about where the work sits. The root carries `DESCRIPTION`, `NAMESPACE`, `R/`, `man/`, `data/`, `inst/`, `vignettes/`, `pkgdown/`, `tests/`, a `DALEX.Rproj` file and a `.Rbuildignore`. Those are the files of an R package, and the badge block at the top of the README leads with CRAN and cranlogs before it gets to PyPI.
The Python package is a subdirectory. Everything specific to it lives under `python/`, with `tox.ini` at the root and a `python/dalex` path named in the README's changelog link. The Python overview is not on this page either; the README sends readers to `ModelOriented/DALEX/tree/master/python/dalex` for it, and the hosted documentation for Python sits on `dalex.drwhy.ai` while the R vignettes are addressed from elsewhere entirely.
So there are two installable artifacts, two documentation sites and one repository, and the branch called `master` produces the R package at its root. The Python metadata you see attached to the project describes the subdirectory, not the thing you get from `install.packages("DALEX")`.
The Python install line carries -U, so every install resolves to the newest release
The R package is installed by name from CRAN:
install.packages("DALEX")The Python package gets two documented routes, and both are printed in one block:
pip install dalex -U
conda install -c conda-forge dalexThe pip line carries `-U`. That is not an incidental flag: it makes each install ask the index for the newest `dalex` rather than honouring a pinned constraint. An environment file or a lock generated from that command records no version, so the same line resolves differently on two machines six months apart. The conda line has no such flag and can be pinned in the usual way, so the two documented routes for the same artifact behave differently under pinning.
Note the case difference too. The R package is `DALEX` in uppercase, the Python package is `dalex` in lowercase, and the repository is named after the uppercase one. On a case-insensitive filesystem a project that vendors both will collide on the directory name.
Three release tags, three naming conventions, and the newest is from 2022
Three releases are published under the repository. The newest is `python-v1.5.0`, dated 2022-09-10. The second is a tag `v1.0.0` whose release title is the bare word `dalex`, dated 2021-01-04. The third is `v1.3`, dated 2020-07-02.
Three conventions in three releases: a language-prefixed tag with a three-part version, a conventional tag with a version, and a two-part version with no leading zero on the minor. `v1.3` and `v1.0.0` are not directly comparable as written, and nothing in the repository states which package either belongs to except the `python-` prefix on the newest one. A build that derives its version from tags cannot tell that the R line and the Python line move independently without special-casing those names.
The gap matters more than the naming. The repository is not archived and its last push is dated 2026-07-15, so the tree has moved nearly four years past the newest published release. Whether PyPI has something newer is not visible from here, and with `-U` in the documented command the answer decides what your environment gets.
Nine R how-to guides are served from third-party GitHub content mirrors
The R resources section links six libraries in one line: keras, parsnip, caret, mlr, H2O and xgboost. Every one of those links points at `rawgit.com` or `raw.githack.com`, and three more links do the same: the cross-language GBM comparison, the fraud detection vignette and the teaching vignette. That is nine of them.
None is hosted on a project domain. The project runs `dalex.drwhy.ai`, `drwhy.ai` and a GitHub Pages site for the e-book, and all seven Python documentation links point at `dalex.drwhy.ai`. The nine R links point somewhere else entirely, at `pbiecek/DALEX_docs/master/vignettes/`, which is a personal repository rather than an organisation one, reached through a content mirror service instead of through the project's own infrastructure.
The practical effect is that the R integration guides depend on two external parties rather than one. They are static HTML served from a fork, and whether they track the current `master` branch is a question about that fork, not about the package on CRAN. The Python guides have no such split: they are served from the project's own documentation site, versioned with the docs rather than with a fork.
The case for the package opens with four chained consequences and no measurement
The Overview opens with a chain of four sentences and no number in any of them: an unverified black box model is the path to the failure, opaqueness leads to distrust, distrust leads to ignoration, and ignoration leads to rejection. That is the entire argument for needing explanation tooling, and it is asserted rather than demonstrated on this page.
The section that follows, headed Learn more, makes the case in prose instead: models built by boosting, bagging or neural networks are hard to trace from input variables to outcomes, they are used because of their performance, and their lack of interpretability is one of their weakest sides. Two sentences in that paragraph are broken. One reads that these models "are use because of high performance", missing the verb ending, and an earlier sentence in the Overview spells the word developments as "developents". Small slips, but they sit in the two paragraphs that are doing the persuading.
None of that makes the package wrong. It makes the landing page unsourced: there is no case study, no benchmark and no measured claim anywhere in it, and the quantitative case has to come from the linked vignettes instead.
explain() wraps a model, and DALEXtra wraps the library it came from
The mechanism is one function. `explain()` creates a wrapper around a predictive model, and the wrapped model is then explored and compared with a collection of local and global explainers. Everything else in the package is a way of asking questions of that wrapper.
The per-library glue lives in a different repository. `ModelOriented/DALEXtra` is described as an extension of `DALEX` offering ready-made `explain_*()` functions for models created with `scikit-learn`, `keras`, `H2O`, `tidymodels`, `xgboost`, `mlr` or `mlr3`, and the framing is aimed at people who already work in those libraries. The Python side has no named counterpart on this page. What it has instead is a feature list: pages for residuals, shap and lime explainers, a Fairness module, and Arena, described as an interactive dashboard for model exploration.
That split has a consequence for adoption. A team on scikit-learn reads one page here and is then sent to a second project for the call that constructs the wrapper. A team writing its own wrapper by hand stays inside `DALEX` and owns the adapter code. Both are supported paths, but only one of them has an entry point named after your library.
Two changelogs, and a BibTeX block that is tagged html
The tree holds a `NEWS.md` at the root and a `python/dalex/NEWS.md` below it, which is the pair you would expect from two packages sharing a repository. The README's changelog link points at the second one, so anyone tracking Python changes from the project page lands in the right file and the root `NEWS.md` has no incoming link from there.
The Citation section closes the README, and it is fenced as `html` while containing BibTeX: two `@article` entries for JMLR papers, one for the R package from 2018 in volume 19, number 84, and one for the Python package in volume 22, number 20, authored by Hubert Baniecki, Wojciech Kretowicz and Piotr Piaty. The language tag is wrong for what the block contains. Any tooling that reads the fence type will treat it as markup, and copy-paste into a `.bib` file works only because a reader ignores the tag.
Licensing is the one place with nothing to reconcile. The declared license is GPL-3.0, a `LICENSE` file sits in the root, and the README links to it. If your organisation has a policy question about GPL in a shipped product, this is the package where the answer is written down rather than inferred.
Editorial conclusion
DALEX is worth reading the source layout of before adopting, because the repository is not the unit of release. The R package is the one whose files sit at the root and whose CRAN badge leads the page; the Python package lives under `python/` and carries its own tag prefix. Pin each one separately, and read the version off PyPI or CRAN rather than off the release list, whose newest entry is `python-v1.5.0` from 2022-09-10 while the last push is dated 2026-07-15. Anyone wiring explainers into a shipped pipeline should also confirm two things for themselves: that the explanation output matches what their compliance reviewer expects, and that the DALEXtra path applies to their model library, since DALEX itself documents the wrapper and defers the per-library glue to a second package. Teams looking for a maintained model-monitoring stack with a steady release cadence will find the signals mixed here. The license is GPL-3.0 with a LICENSE file at the root, which is the one piece of the packaging that needs no interpretation.
Frequently asked questions
What does the DALEX package do?
Its main function explain() creates a wrapper around a predictive model. Wrapped models can then be explored and compared with a collection of local and global explainers, which the project positions as model explanation tooling.
Which languages does DALEX support?
One repository ships two packages: the R package DALEX installed from CRAN, and the Python package dalex available on PyPI and conda-forge. The R files sit at the repository root and the Python package lives under the python directory.
How do I install the dalex Python package?
Two documented routes: pip install dalex -U, which resolves to the newest release on every run, and conda install -c conda-forge dalex, which can be pinned the usual way. The R side uses install.packages("DALEX") from CRAN.
What is DALEXtra and when would I need it?
DALEXtra is a separate package in ModelOriented/DALEXtra that extends DALEX with explain_*() convenience functions for models created with scikit-learn, keras, H2O, tidymodels, xgboost, mlr or mlr3.
Which explainers does the Python dalex package include?
Its documentation covers residuals, shap and lime explainers, plus a Fairness module and Arena, which is described as an interactive dashboard for model exploration.
Official sources
Add this badge to your README
If you maintain this project, the badge below links readers to this analysis and shows its maintenance status from the daily GitHub snapshot. Paste the markdown into your README; add ?metric=license or ?metric=stars to the image URL for a different field.
[](https://hysenlabs.com/projects/modeloriented-dalex)