# MetaPython: Meta's Production Fork of CPython Tracking Python 3.14 > MetaPython is Meta's internal fork of CPython, currently tracking Python 3.14. It carries the production patches that Meta's infrastructure teams maintain and apply to the standard Python runtime. The related JIT compiler and Python extensions have been moved to the separate facebookincubator/cinderx repository. **facebookincubator/MetaPython** — This is Meta's fork of the CPython runtime. The name "cinder" here is historical, see https://github.com/facebookincubator/cinderx for the Python extension / JIT compiler. - Repository: https://github.com/facebookincubator/MetaPython - Stars: 3,795 · Forks: 139 - Language: Python - License: NOASSERTION - Published: 2026-09-23 · Updated: 2026-09-23 · Language: en - Canonical page: https://hysenlabs.com/projects/facebookincubator-metapython ## What MetaPython Is and Why It Exists CPython, the reference Python implementation, is a shared foundation that Meta and many other large organizations build on. When a company runs Python at infrastructure scale, it typically accumulates patches: bug fixes that have not yet been accepted upstream, performance improvements specific to their hardware and workload patterns, or behavior changes needed to maintain compatibility with their internal tooling. MetaPython is where Meta maintains these patches for the CPython 3.14 runtime. The default branch is `meta/3.14`, indicating that the repository tracks the `3.14` line of CPython with Meta's changes layered on top. The README describes this as Python version 3.14.7+. The repository description mentions that the name "cinder" is historical. What was once Cinder, Meta's name for its modified CPython, has been split: the core runtime fork is now MetaPython, and the Python extension module and JIT compiler work has moved to a separate repository at facebookincubator/cinderx. This separation means MetaPython is now specifically the CPython runtime fork, not the full performance stack. The repository's last push was on 2026-09-27, indicating ongoing tracking of CPython development. ## Building MetaPython: Standard CPython Steps The README is the standard CPython build README, which reflects the nature of this repository: it is a fork of CPython, and the build process is identical to building upstream CPython. On Unix, Linux, BSD, macOS, and Cygwin: ```bash ./configure make make test sudo make install ``` This installs Python as `python3`. The `./configure` script accepts many options; running `./configure --help` lists them. For a debug build: ```bash mkdir debug cd debug ../configure --with-pydebug make make test ``` Note that a debug build in a subdirectory will fail if you have also built at the top level. Run `make clean` at the top level first. For an optimized build, the README recommends running with Profile Guided Optimization before distributing: ```bash ./configure --enable-optimizations ``` This sets up PGO, which runs an instrumented interpreter build, profiles it against a training workload, and then produces a final binary optimized based on that profile data. Link Time Optimization is enabled separately: ```bash ./configure --with-lto ``` LTO allows the compiler to optimize across object file boundaries when building the final interpreter binary. ## Testing the Build The README documents the test suite entry point: ```bash make test ``` The test set produces output but you can generally ignore messages about skipped tests for optional features that cannot be imported. If a test fails, run the failing tests in verbose mode to get more context: ```bash make test TESTOPTS="-v test_os test_gdb" ``` For tests that require more resources than the defaults allow, such as tests that use large amounts of disk space or memory: ```bash make buildbottest ``` The test infrastructure is identical to upstream CPython's. Failures that reproduce in both MetaPython and upstream CPython are upstream issues; failures that appear only in MetaPython indicate a problem in Meta's patches. The repository layout mirrors CPython exactly: `Lib/` holds the standard library, `Modules/` holds C extension modules, `Objects/` holds core type implementations, `Python/` holds the interpreter core, `Include/` holds public headers, and `Doc/` holds documentation sources. Platform-specific code lives in `Mac/`, `iOS/`, `Android/`, and `Apple/` directories alongside `PC/` and `PCbuild/` for Windows. ## What Meta's Fork Actually Changes The README does not document which specific patches Meta applies beyond CPython. The repository description references the cinderx repository for the JIT compiler and Python extensions, which implies that MetaPython itself contains the runtime-level patches while JIT and extension work stays in the separate repository. The practical implication is that reading this repository's commit history against upstream CPython `3.14` is the primary way to understand what Meta changes. The `meta/3.14` branch contains the full divergence history. CPython 3.14 documentation is available online at `docs.python.org/3.14`, updated daily, and downloadable in HTML, EPUB, and reStructuredText. This documentation covers the standard library and language features but not Meta's specific patches, which would need to be understood through the diff against upstream. The repository includes `.azure-pipelines/` and `.github/` directories, suggesting CI pipelines exist for both Azure and GitHub Actions. The upstream CPython CI workflow badge references `github.com/python/cpython`, not this repository, since the README was inherited from CPython. ## License and Why It Matters The GitHub license field for MetaPython is listed as NOASSERTION. This is a non-standard license identifier that appears when a repository's license cannot be automatically detected or when no standard license has been declared. It does not mean the code is in the public domain or free to use; it means the distribution terms are unresolved as far as GitHub's detection is concerned. CPython itself is distributed under the Python Software Foundation license (PSF-2.0), which is a permissive open-source license. The META fork layers additional patches on top, and the terms that govern those additional patches are not clearly stated in the NOASSERTION case. Teams that need clarity before incorporating MetaPython code into a product should contact Meta directly or consult legal counsel. The NOASSERTION designation is a material consideration that upstream CPython does not carry. Upstream CPython from `github.com/python/cpython` is the natural alternative. The difference is that MetaPython carries Meta's production patches, which may include bug fixes and behavior changes that are not yet in the upstream `3.14` branch. Teams that neither work at Meta nor need to track Meta's specific patches should use upstream CPython directly. ## Multiple Python Versions and the cinderx Connection The README documents how to install multiple Python versions side by side, which is useful when MetaPython needs to coexist with the system Python or other versions. The standard CPython approach applies here. The separation between MetaPython and facebookincubator/cinderx is architecturally significant. In earlier versions of Meta's Python work (the Cinder era), the JIT compiler, eager evaluation, and other performance features were embedded directly in the modified CPython fork. The split into MetaPython and cinderx means the JIT is now a Python extension module that loads into MetaPython rather than being compiled into the interpreter itself. This architecture allows Meta to update the JIT and runtime fork independently. For anyone interested in the performance work specifically, cinderx is the repository to examine. MetaPython is the platform that cinderx runs on. The repository includes `InternalDocs/` in its top-level layout, which upstream CPython added to hold documentation about CPython internals. This directory holds descriptions of the interpreter's data structures and algorithms rather than end-user documentation. ## Conclusion MetaPython is appropriate for teams that want to track Meta's production-tested CPython patches ahead of upstream merges, or that need to understand how Meta diverges from standard CPython for compatibility reasons. It is not a drop-in alternative to CPython for general projects: the GitHub license is listed as NOASSERTION, which means the distribution terms are unclear and require investigation before use. Teams running standard Python workloads should use the official CPython distribution from python.org. The JIT and extension work, historically named Cinder, now lives in facebookincubator/cinderx rather than in this repository. ## FAQ ### What is the difference between MetaPython and standard CPython? MetaPython is Meta's fork of CPython that tracks the Python 3.14 line and adds Meta's internal production patches on top. The JIT compiler and Python extension work, previously part of Meta's Cinder project, now lives separately in facebookincubator/cinderx. Upstream CPython from python.org does not include Meta's patches. ### What happened to Cinder, Meta's previous Python project? Cinder was Meta's earlier name for its modified CPython. The work has been split into two repositories: MetaPython holds the CPython runtime fork, and facebookincubator/cinderx holds the JIT compiler and Python extension module. The repository description states the name Cinder is now historical. ### Why does MetaPython show NOASSERTION as its license? NOASSERTION appears when GitHub's license detection cannot identify a standard license. It does not indicate free use; the distribution terms of Meta's patches are not clearly declared in the repository. The underlying CPython code is under the PSF license, but the status of Meta's additional patches should be verified before incorporating them into a product. ## Sources - [facebookincubator/MetaPython on GitHub](https://github.com/facebookincubator/MetaPython) - [Issues](https://github.com/facebookincubator/MetaPython/issues) - [README](https://github.com/facebookincubator/MetaPython/blob/meta/3.14/README.md) --- Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/facebookincubator-metapython