frictionless-py: a DEVT framework for tabular data with a real validator

Describe, extract, validate, transform

frictionless-py is a data management framework for Python that provides functionality to describe, extract, validate and transform tabular data, which the README abbreviates as the DEVT framework. The four verbs are the whole architecture, and each one has a defined audience. Describe is the step where you infer, edit and save metadata about a data table, which the README calls a first step for ensuring data quality and usability. Extract is reading, through a unified tabular interface, with data quality and consistency guaranteed by a schema. Validate produces a report. Transform cleans, reshapes and transfers tables and datasets. Underneath all of it sits the Frictionless Standards, described as lightweight yet comprehensive, and the framework also provides integrations with popular platforms. The result is a package that treats a CSV file with a schema as a first class object rather than as rows of strings.

Metadata is the artefact you keep

The describe step deserves more attention than it usually gets, because it is the step that changes the shape of a project. You can infer, edit and save the metadata of your data tables, and that metadata includes general information about the data such as a textual description, along with field types and other tabular data details. Once a table has a saved description, every consumer of that table, a validator, a transformation, a documentation generator, is working from the same source of truth about what the fields mean. The alternative, which is what most teams end up with, is a spreadsheet of column definitions maintained separately from the data, and that spreadsheet is wrong within a month. The frictionless approach is that the description travels with the data, and the standards it is based on mean the description is not locked to this implementation.

One read interface over many sources and formats

The extract side is about removing the branching that comes with file handling. You read your data using a unified tabular interface, and data quality and consistency are guaranteed by a schema, which means the reader is not just a convenience wrapper, it is the enforcement point. The coverage is broad. Frictionless supports various file schemes like HTTP, FTP and S3, and data formats like CSV, XLS, JSON, SQL and others, and the feature list adds support for compressed files. That combination is the reason a publisher can point a consumer at a file without caring whether it sits on a local disk or behind an S3 bucket, and it is also the reason the framework is used in pipelines rather than in notebooks. A related claim in the feature list is low memory consumption for data of any size, with reasonable performance on big data, and petl appears in the dependency list, which is the tabular data library doing the heavy lifting under the hood.

Validation with a report you can act on

You can validate data tables, resources and datasets, and the framework generates a unified validation report as well as supporting a lot of options to customise the validation process. The report format is the part to judge, because a validator that only says something is wrong is not much better than a script. The command in the README shows a table of rows, fields, codes and messages, with codes such as blank-header, duplicate-header, missing-cell, blank-row and extra-cell, each pointing at the row and field at fault:

$ frictionless validate data/invalid.csv
[invalid] data/invalid.csv

  row    field  code              message
-----  -------  ----------------  --------------------------------------------
             3  blank-header      Header in field at position "3" is blank
             4  duplicate-header  Header "name" in field "4" is duplicated
     2        3  missing-cell      Row "2" has a missing cell in field "field3"

Custom checks and formats are listed among the features, so the vocabulary of problem codes is extensible rather than fixed, which is what lets a team encode its own rules alongside the structural ones.

Transform: a pipeline and a lower-level interface

The transform verb is described as cleaning, reshaping and transferring data tables and datasets, and the framework provides a pipeline capability and a lower-level interface to work with the data. Having both is the design decision that matters here. A pipeline is what you use when the transformation is a sequence of well understood steps that someone else can read from the configuration, while the lower-level interface is what you reach for when the shape of the change is specific enough that expressing it as a sequence of steps would obscure the intent. Projects that migrate from pandas and spreadsheet formulas tend to land on the second one, because the first is where the framework earns its keep in a scheduled pipeline. The dependency list backs that up, with petl and marko handling the tabular and markup work, and pydantic, jsonschema and referencing handling the typed description side.

A command line interface and a Python API

One of the listed features is a convenient command-line interface, and the frictionless validate command shown above is the whole entry point for the most common task, which is finding out whether a file is fit to publish. Underneath it there is a Python package, frictionless, installed from PyPI with pip install frictionless, and the package is what you use when the validation is a step inside a larger script rather than something you type by hand. The command line tool is built on typer, which is in the dependency list, and the output rendering uses tabulate, which explains the aligned column layout of the report. The framework also exposes the familiar option of custom checks, so a project can register its own rules and have them appear in the same report format.

Dependencies, licence and the v5 migration

The package metadata is a fair summary of the trade-offs. The licence is MIT, the development status is 5 - Production/Stable, the operating system is OS Independent, and Python 3.8 through 3.14 are classified as supported, with requires-python set to >=3.8. The dependency list is long for a data library, with petl, marko, attrs, jinja2, pyyaml, isodate, rfc3986, a version split of chardet around Python 3.10, pydantic, requests, humanize, tabulate, jsonschema, referencing, simpleeval, typer, validators and python-slugify, and that is the price of supporting many formats and a typed description layer in one package. The authorship is credited to the Open Knowledge Foundation, and the keywords list data validation, json schema, json table schema, data package and tabular data package, which are the standards vocabulary. The README also carries a migration note at the top, telling users coming from an older version to read the v5 announcement and migration guide, and that is not a formality, since the framework went through a major rewrite at v5 and the repository carries a MIGRATION.md, a CHANGELOG.md, a blog directory and a CITATION.cff. The releases move steadily, with v5.20.0rc2 in September 2026, v5.20.0 in October and v5.21.0 on 2026-10-15, and the last push was on 2026-10-15 with the repository not archived.

Editorial conclusion

frictionless-py fits a data team that publishes datasets, where the same table has to be validated, documented and transformed for several consumers, and it fits a team that has been describing its CSV files in prose and wants a machine readable description instead. It is the wrong choice for a small script that only needs to read a CSV, since the dependency list is long for that job, and it is a poor fit if you are still on the version 4 API, because the v5 rewrite changed enough that the migration guide is not optional reading. Before you adopt it, read the v5 announcement and migration guide, check that your Python version is inside the supported range, and validate one real file with the CLI to see whether its report matches the checks you actually care about.

Frequently asked questions

Official sources

1. frictionlessdata/frictionless-py on GitHub
2. License: MIT
3. Project website
4. README
5. Releases