pandas builds with meson-python and excludes numpy 2.5.0 on purpose

The build backend is meson-python, and Cython is not optional

The build-system table in pyproject.toml is the part of the repository that changed the installation story. The backend is mesonpy, and the requirements are a meson-python between 0.19.0 and 1, meson between 1.2.3 and 2, wheel, Cython above 3.1.0 and below 4, and versioneer. A source install therefore needs a build system, a compiler and Cython before pandas itself is involved.

That is what the README means when it says installing from sources requires Cython in addition to the normal dependencies:

pip install cython

and then, from the cloned directory:

pip install .

A development-mode install is offered as the alternative. The practical consequence for a reader is that `pip install pandas` from PyPI and `pip install .` from a clone are not the same operation. The first takes a wheel, and the second compiles the extension modules on your machine, which is where a missing toolchain shows up.

The version itself is not in pyproject.toml at all. The name is declared with dynamic = ['version'], the build wiring around it is versioneer[toml], and the repository carries both generate_version.py and generate_pxi.py for code generation at build time.

Wheels are built against numpy 2 to stay compatible with numpy 1

The numpy bound in the build requirements carries a three-line comment explaining itself: numpy >= 2.0.0 keeps wheels compatible with numpy 1 and 2, and 2.5.0 is excluded on purpose. The reason given is that wheels built against 2.5.0 segfault on older numpy, citing the NumPy issue and noting it was fixed in 2.5.1.

The written requirement is `numpy>=2.0.0,!=2.5.0`. A reader pinning dependencies by hand will not find that exclusion anywhere else, and an environment that happens to have 2.5.0 installed satisfies a naive `>=2.0.0` check. That is the sort of detail that turns into an unexplained crash report rather than a resolution error, so the constraint belongs in your own lockfile, not just in the build metadata.

There is a second, quieter bound next to it. The Cython constraint is written as Cython>3.1.0,<4 rather than with the patch form, and the comment explains that a pre-release in the bound makes pip eligible to install Cython pre-releases, which pulled a 3.3.0a1 alpha into 3.0.4. The same comment asks that the bound be kept in sync with environment.yml and asv.conf.json, which tells you this is a value maintained in three files by hand.

Alignment is the behaviour that leaks into everything else

The feature list leads with missing data handling, represented as NaN, NA or NaT in floating point and non-floating point data, then with size mutability, where columns can be inserted and deleted from DataFrame and higher dimensional objects. The third entry is the one that shapes the rest: automatic and explicit data alignment, where objects can be aligned to a set of labels or the labels can be ignored and Series, DataFrame and the rest align the data for you in computations.

That single decision is why combining two frames of different shape does not raise, and why it occasionally produces NaN where you expected a row. It is also why group by is described as split-apply-combine rather than as a single operation, and why merging, joining, reshaping and pivoting all read as variations on the same idea of labels meeting.

The rest of the list is a catalogue of consequences of that model: hierarchical labelling of axes so a tick can carry multiple labels, label-based slicing with fancy indexing and subsetting, and conversion of ragged, differently indexed data from other Python and NumPy structures into DataFrame objects. Time series support is separate rather than derived, covering date range generation, frequency conversion, moving window statistics, and date shifting and lagging. I/O is described as robust for flat files, Excel, databases, and the HDF5 format.

asv_bench, ci/ and pixi.lock are three different answers to reproducibility

The top level of the repository shows how the project is kept honest, and there are three distinct mechanisms doing it.

asv_bench/ is the performance benchmark suite, which is how a library that rewrites its Cython internals every release detects a regression nobody noticed. ci/ holds the continuous integration definitions. pixi.toml with pixi.lock is a separate environment definition from a lock file, and environment.yml is the Conda-side equivalent, which is the third place the Cython bound has to be kept in step.

Around those, .pre-commit-config.yaml gates commits, codecov.yml tracks coverage, pyright_reportGeneralTypeIssues.json records a static typing report, and LICENSES/ holds the vendored licence texts. A contributor therefore has to satisfy a formatter, a type report, a coverage number and a benchmark comparison before a change lands, which is a reasonable explanation for a release cadence measured in months rather than days.

The licence is BSD-3-Clause plus fourteen vendored licence texts

pandas itself is BSD-3-Clause, stated in pyproject.toml with license = 'BSD-3-Clause' and a LICENSE file at the root. The licensing section then lists every other licence that ships inside the distribution, each with the file that carries it:

license-files = [
    "LICENSE", # BSD-3-Clause
    "LICENSES/BOTTLENECK_LICENCE", # BSD-2-Clause
    "LICENSES/DATEUTIL_LICENSE", # Apache-2.0
    "LICENSES/HAVEN_LICENSE", # MIT
    "LICENSES/KLIB_LICENSE", # MIT
    "LICENSES/MUSL_LICENSE", # MIT
    "LICENSES/NUMPY_LICENSE", # BSD-3-Clause
]

The full list runs to seventeen entries when the bundled subprojects are counted, including a fast_float subproject that ships its own LICENSE-APACHE, LICENSE-BOOST and LICENSE-MIT files. The licences range across BSD-2-Clause, BSD-3-Clause, Apache-2.0, MIT, PSF-2.0, BSL and one entry marked BSD-3-Clause AND TCL for Pyperclip.

This is ordinary practice for a scientific Python package and it is still worth reading if you redistribute. The permissive licences dominate, but the list is the authoritative statement of what you are shipping, and the vendored files are in the repository rather than only on a website.

Getting pandas is a wheel, not a build, unless you clone

The supported install routes are two commands:

# conda
conda install -c conda-forge pandas

# or PyPI
pip install pandas

Binary installers for the latest released version come from the Python Package Index and from Conda, and the source is on GitHub. Which route you take decides what you get: a wheel from either index, or a compiled build from a clone.

The runtime dependencies are short by design. NumPy supplies the large, multi-dimensional arrays and the mathematical functions that operate on them. python-dateutil extends the standard datetime module. tzdata provides the IANA time zone database and is required only on Windows and Emscripten, which is the one platform-specific dependency in the list. The minimum supported versions of required, recommended and optional dependencies are documented separately, and the optional set is where Excel, SQL and HDF5 support live, so a minimal install gives you less than the feature list implies.

Patch releases are frequent, and the major version is the risk boundary

The last push to the default branch main is dated 2026-09-26, and the release list shows v3.0.6 on 2026-09-17, v3.0.5 on 2026-07-22 and v3.0.4 on 2026-06-28. Three patch releases inside three months on a project of this size is a healthy maintenance signal, and it is also a reminder that the interesting upgrade decision is 2.x to 3.0 rather than any of these.

The repository carries the migration paperwork in the usual place: the list of changes between each release lives in the documentation's whatsnew pages, and the commit logs are on GitHub for anyone who needs the detail the release notes leave out. AGENTS.md at the root, AUTHORS.md, CITATION.cff for citation metadata, and a Zenodo DOI badge are all in the tree.

What the repository does not do is tell you which of your own code will break. There is no compatibility shim documented, and a library that changed its build system, its dependency floor and its default behaviour between 2.x and 3.0 will have moved something a deprecation notice in your dependency file never mentioned. Read the 3.0 release notes against your own usage before upgrading, not after.

Editorial conclusion

Adopt pandas if your work is tabular or time series data in Python, because the alignment and groupby semantics are the reason the library is hard to replace, and because the 3.0 line is still taking patch releases: v3.0.6 shipped on 2026-09-17 after v3.0.5 and v3.0.4, with the last push on 2026-09-26. Do not adopt it expecting a pure-Python install to be equivalent, because the build compiles Cython extensions through meson and needs a compiler toolchain plus Cython even for a source install. Two things to check before you pin a version. Read the build requirements in pyproject.toml rather than trusting a wheel, and note the comment next to the numpy bound: wheels are built against numpy 2 to stay compatible with numpy 1, and 2.5.0 is excluded because wheels built against it segfault on older numpy. And check the licence set, which is BSD-3-Clause for pandas itself and then fourteen vendored licences for Bottleneck, dateutil, NumPy, PyArrow-adjacent pieces and the bundled subprojects.

Frequently asked questions

Official sources

1. Official documentation
2. Official README
3. Project repository
4. Release notes