ivy: transpiling machine learning code between PyTorch, TensorFlow, JAX and NumPy

PyTorch in, three frameworks out

The conversion matrix in the documentation is the first thing to read, and it is narrower than the project name suggests. Four frameworks are listed, with a column for source and a column for target. PyTorch has a tick in the source column and nothing but a note in the target column. TensorFlow, JAX and NumPy are the mirror image, unsupported as sources and ticked as targets.

Read that carefully and it means one thing: today you can write PyTorch and run it as TensorFlow, JAX or NumPy, and the other direction is not supported. The table is titled as the frameworks that ivy.transpile currently supports conversions from and to, so those ticks and gaps are the whole of the claim.

The asymmetry is structural rather than an oversight. ivy works by taking code written against one framework and rewriting it against another, and the rewrite is built by tracing code in the source framework, so the source has to be the one ivy can execute and understand. The result is a tool that is best described as a PyTorch to other frameworks converter wearing a symmetric name.

transpile is eager for a function and lazy for a library

The two entry points are ivy.transpile and ivy.trace_graph, and the behaviour of transpile depends on what you hand it. When a class or a function is provided, transpilation happens eagerly: the returned object is already target framework code, and the documentation is explicit that it runs efficiently in that form.

When a module, meaning a whole library, is provided, the transpilation is lazy instead. The conversion is initialised on the first call, and that call is the one that gets converted.

import ivy
import kornia
import tensorflow as tf

x2 = tf.random.normal((5, 3, 4, 4))

# Module is provided -> transpilation happens lazily
tf_kornia = ivy.transpile(kornia, source="torch", target="tensorflow")

# The transpilation is initialized here, and this function is converted to tensorflow
ret = tf_kornia.color.rgb_to_grayscale(x2)

That difference matters in practice. A lazy module conversion is what makes a third party library usable under another framework, since you are not rewriting its source, you are letting it be converted on first use. The example above uses a vision library as the module and asks for a single colour space conversion, which is the shape of the problem this library is built for.

trace_graph produces a functional graph from a function

The second entry point traces a computational graph rather than converting a call site. The description given is that it traces an efficient fully functional graph from a function, removing all wrapping and redundant code, and the resulting graph is then callable with the same arguments. The call takes the framework you want as the target, a to argument, plus the arguments of the function in an args tuple, and the graph comes back as a value you can invoke.

That is a different tool from transpile. Transpile rewrites a body of code into another framework's dialect, while trace_graph gives you a callable that has been reduced to its essential operations, which is what you want when the goal is to strip overhead out of a hot path rather than to change dialects.

One caution about the documentation snippets themselves. In the eager transpilation example, the function passed to ivy.transpile is not the function defined immediately above it, and in the tracing example the name handed to ivy.trace_graph is not the one defined above either. The described behaviour is clear enough to use, but the examples have not been rechecked recently, so expect to fix a name or two when you first run them.

Installing from PyPI, or from a clone when you want the newest changes

The easy path is a single pip command.

pip install ivy

The alternative, for when you want the latest changes rather than the published version, is to clone and install in editable mode.

git clone https://github.com/ivy-llc/ivy.git
cd ivy
pip install --user -e .

The repository has a helper for the dependency side of that, an install_dependencies.sh script at the root, and a requirements/ directory that the editable install uses. There is also a .gitmodules file, which means some components of the project are pulled in as submodules rather than vendored.

The build configuration is ordinary setuptools. The pyproject.toml build system requires setuptools of at least version 42, wheel and pip, and the linters are configured in the same file: ruff with a line length of 88 and a target of py38, autoflake for unused imports, and docformatter for docstring wrapping.

The licence is Apache 2.0 in the setup header but unclassified on GitHub

The licence is the detail to check before you build on this. The licence field on the repository is one that GitHub cannot classify, and the file it points to is the LICENSE file, while the header in setup.py states the Apache License, Version 2.0, in the usual form. So the source files claim Apache 2.0 and the repository's own classifier cannot map the licence file to a standard category, which usually means the file carries extra terms or a modified form.

This is not legal advice, and the only sound move is to read the LICENSE file yourself and decide from the text. It is worth doing early, because the position is unusual enough that a licence scanner in your build pipeline will likely flag it.

The version scheme deserves a note too. The published releases are 1.0.0.3 on 2025-01-22, 1.0.0.4 on 2025-02-21 and 1.0.0.5 on 2025-06-16, so the patch component is where the movement happens. The last push to the repository was on 2026-10-16, which means the tree is considerably newer than the newest published version.

A 2021 paper behind a 2026 repository

The academic framing of the project is fixed in its citation entry, an article titled Ivy: Templated deep learning for inter-framework portability by Lenton, Pardo, Falck, James and Clark, from 2021, with the arXiv identifier arXiv:2102.02886. The repository also carries a CITATION.cff file.

The documentation is published separately at ivy-llc.github.io/docs, with a demos and examples page, a contributing guide and a page of open tasks. The example code in the repository is split across two directories, one holding examples that are finished and one holding work in progress, and the tests live in a separate ivy_tests/ directory rather than inside the package, which keeps the shipped package smaller.

For a project that a research group points to in a paper and then keeps shipping, the shape is unusual but explicable: the idea is a templated approach to inter-framework portability, and the code is a research artefact that has to keep tracking four frameworks that all move quickly. The practical consequence for a user is that the documentation site and the published version are two different things, and the matrix of what actually converts is the thing to check first.

Editorial conclusion

ivy is worth evaluating when you have a PyTorch model and a hard requirement to run it under TensorFlow, JAX or NumPy, because the lazy module path lets you convert a third party library instead of rewriting it. It is the wrong tool if your code is already in one of those frameworks, since the matrix currently supports PyTorch only as a source, and it is the wrong tool if you need a production guarantee, since the version line has moved to a 1.0.0.x scheme with the last published release dated 2025-06-16 and the repository pushed to on 2026-10-16. Before you rely on it, read the LICENSE file, because setup.py carries an Apache 2.0 header while the licence itself is not one GitHub can classify.

Frequently asked questions

Official sources

1. Issues
2. Project website
3. README
4. Releases
5. unifyai/ivy on GitHub