calibre: the e-book manager you build from source, not just install

What calibre actually manages, and who ends up using it

The README lists the scope in one paragraph: view, convert, edit and catalog e-books in the major formats, talk to reader devices, fetch metadata from the internet, and download newspapers as e-books. That is a wide brief. The people who get value from it are not readers looking for a prettier viewer. They are the ones holding a library that has outgrown a folder of files: a few thousand EPUBs with inconsistent metadata, a Kindle and a Kobo that both need the same book in different containers, or a set of PDFs that need to become reflowable text.

The repository itself is the official source, and the README points elsewhere for everything else. Usage goes to the User Manual at manual.calibre-ebook.com. Bug reports go to Launchpad, with the note that GitHub is only used for code hosting and pull requests. That split matters more than it looks. If you file an issue on GitHub expecting triage, the README says you are in the wrong place.

The Python 3.14 floor and the dependency list as an architecture statement

pyproject.toml declares requires-python = ">=3.14", and setup.py enforces it before anything else runs. The check reads the value out of pyproject.toml with a regular expression, compares it against sys.version_info, and exits with a message naming the required version if the interpreter is too old. There is no fallback path and no attempt to degrade gracefully. If you are on an older Python, the build stops at the first line of setup.py.

The dependency list is the more informative artefact. It includes apsw, a SQLite binding, which is consistent with a catalogue stored in a database rather than a flat index. It includes lxml, html5-parser, css-parser, beautifulsoup4 and html2text, which is what you would expect from a converter that has to parse and rewrite markup rather than shuffle bytes. It includes PyQt6 and PyQt6_WebEngine, so the desktop interface is Qt, and the same tree ships a command line. It pins exact versions with == rather than ranges, which means the source tree is tested against one known set of libraries and upgrading any single dependency is a deliberate act.

Two entries stand out. browserforge and apify_fingerprint_datapoints, with click pulled in for browserforge and camoufox mentioned in the comment, suggest browser automation used when fetching metadata or news. That is a design choice with a cost: the fetching side depends on packages whose purpose is to look like a normal browser, and those move faster than the rest of the list.

Installing calibre and converting your first book

The README does not give installation instructions. It points to the About page at calibre-ebook.com and to the User Manual, and for building binaries it points at bypy/README.rst. The tarball of the current release source is at calibre-ebook.com/dist/src. So the honest first step is to get it from the project's own distribution rather than from this repository.

If you are building from source, the entry point is setup.py, and the first thing it does is check your interpreter. The repository shows the version check running before anything else:

check_version_info()

That call reads requires-python out of pyproject.toml, compares it against sys.version_info, and exits with a message naming the required Python and your current one if the interpreter is too old. Nothing else runs in that case. Once it passes, the manual's develop.html page is the documented route for a development environment.

For the everyday case, the repository documents the interpreter floor rather than a usage command line, and it sends you to the User Manual for how to actually run the tool. The one thing the source tree makes explicit is the version gate:

sys.exit(f'calibre requires Python {minver}. Current Python version: {".".join(map(str, sys.version_info[:3]))}')

That is the exact message setup.py prints when the check fails, naming both the required minimum and the interpreter it found. If you see it, install a newer Python before going further; there is no override flag in setup.py.

Expect a PDF to EPUB conversion to need editing: PDF is a fixed layout and the conversion is a reconstruction, not a copy. The README describes editing as one of the four things calibre does, which is the acknowledgement that conversion output is a starting point.

Sending a book to a reader is the other common first task, and the README's claim that calibre "can also talk to e-book reader devices" is the whole of what the repository says about it. The device-specific procedure lives in the User Manual, not here.

Where calibre is the wrong tool

The README is silent on rollback. There is no documented procedure for reverting a release, no migration guide for the catalogue database, and no statement about what happens to an existing library when you move between versions. If you are deploying calibre for other people rather than for yourself, that silence is the risk you are accepting.

The second limitation is structural. calibre is a desktop application with a Qt interface and a catalogue, and the README describes it as cross platform on Linux, Windows and macOS. Nothing in the repository describes a hosted or multi-user service. If your requirement is a shared library that several people reach through a browser, the source tree does not present itself as that, and the search data around calibre web points at a different kind of project rather than at a mode of this one.

The third is the one people hit first. Conversion quality depends on the source format. A PDF carries layout, not structure, and calibre has to infer the structure. The README does not promise fidelity, and the presence of a separate editing component is the practical answer: convert, then fix.

calibre versus a format-specific converter

The real alternative is not another library manager. It is a narrow converter such as Pandoc, which takes a document in one markup format and produces another. The difference in approach is the unit of work. Pandoc operates on a document you hand it and returns a document; it has no catalogue, no device transfer, no metadata fetching, and no persistent library. calibre operates on a library, and the conversion is one operation inside it.

That distinction decides the choice. If you have a pipeline that turns Markdown into EPUB as part of a build, a document-level converter is the smaller dependency and the one that fits. If you have books, and you want them catalogued, converted, edited and moved to a reader from one place, calibre is doing work that Pandoc was never designed to do. The dependency list in pyproject.toml, with PyQt6 and a SQLite binding, is the price of that scope.

Maintenance, releases and the licence you are accepting

The repository is not archived, and the last push was on 2026-08-28, which is the same date as the v9.14.0 release. The two releases before it, v9.13.0 and v9.12.0, landed on 2026-08-07 and 2026-07-31. Three releases inside a month tells you the cadence is fast, and a fast cadence is a maintenance cost for anyone who builds from source: every release is another build against a pinned dependency set, and the pins move.

The licence is GPL-3.0, declared as GPL-3.0-only in pyproject.toml and as 'GPL v3' in the setup.py header, with LICENSE and LICENSE.rtf at the top level and a COPYRIGHT file alongside them. The practical implication is the ordinary one for a GPL application: if you distribute a modified calibre, the source you distribute has to carry the same terms. Internal use is a different question, and this is the point where you read the licence text rather than an article about it.

Upgrade cost has one more component worth naming. The dependency list is pinned exactly, and it includes browserforge and its supporting packages. Those are the entries most likely to force a change when the fetching side of calibre has to keep working against sites that change. A source build is not a one-time setup.

Editorial conclusion

Adopt calibre if you need one tool that converts, edits and catalogues books across Linux, Windows and macOS, and you accept a GPL-3.0 application whose source build requires Python 3.14 or newer. Do not adopt it if you expect the repository README to walk you through installation, or if you need a documented rollback path for a failed release. Before committing, verify that your distribution packages a current version, that your Python satisfies the requires-python floor, and that the format you care about is handled by the converter rather than by a plugin.

Frequently asked questions

Official sources

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