TensorFlow Privacy: the manifest caps TensorFlow at 2.15 and Python below 3.12

The manifest caps TensorFlow and excludes modern Python

The install requirements in the packaging file are where the real constraints live:

install_requires=[
    'absl-py>=1.0,==1.*',
    'dm-tree==0.1.8',
    'dp-accounting==0.4.4',  # TODO(b/364653784)
    'numpy~=1.21',
    'packaging~=22.0',
    'scikit-learn>=1.0,==1.*',
    'scipy~=1.9',
    'tensorflow>=2.4.0,<=2.15.0',
    'tensorflow-probability~=0.22.0',
],
python_requires='>=3.9.0,<3.12',

Two of those lines decide whether the package installs at all. TensorFlow is bounded on both sides, and the ceiling is a closed one at 2.15.0, so a resolver on a newer TensorFlow either fails or has to ignore the requirement. Python is bounded at the top too, excluding 3.12 and everything above it, which covers the versions most current work is on. Both are expressed here and nowhere in the documentation. A third detail in the same block is worth noting on its own: the accounting dependency carries an unresolved internal tracking comment, which is a work-in-progress marker left in a published manifest rather than a decision recorded anywhere a user would see it.

The documentation states a floor and the manifest states two

Read the setup section and you get a different answer. It says the library uses TensorFlow to define models, so installing TensorFlow, written as version 1.14 or newer, is a pre-requisite, with a pointer to TensorFlow's own instructions and a recommendation to install GPU support for better performance. Later, a section on TensorFlow 2 says the library now works with TensorFlow 2, names the file holding the Keras-based estimators, and adds that for this to work you need TensorFlow 2.4 or later. So the prose gives a floor of 1.14 in one place and 2.4 in another, and never mentions a ceiling. The manifest gives a floor of 2.4.0 and a ceiling of 2.15.0. Three statements about the same dependency, and the two that would actually stop an install are the ones in the file nobody reads before running pip. A reader following the documentation top to bottom on a machine with a recent TensorFlow would find out about the ceiling from a dependency resolver error rather than from the project.

requirements.txt names a different Google project in its header

The development requirements file opens with a policy comment, and the policy is sensible: for a package with a stable release use a compatible release specifier, for one without use an exact version matching a release that has been tested, and follow semantic versioning otherwise. The file also records a pip bug it has to work around, one where multiple packages using the compatible release operator and a version ending in zero misbehave, with a link to the issue and instructions to use a greater-than-or-equal with an exact wildcard instead. Then the first instruction line says that if you add a new dependency required by the TensorFlow Federated package, you should also add it to the setup file. This is a TensorFlow Privacy repository. The requirement bookkeeping instruction is written for a different project in the same family, which suggests the file was copied from there and the reference was not updated. The list itself follows the stated policy, and it is much longer than the install requirements in the manifest, adding dataframes, plotting, statistics, dataset and estimator packages that a user installing the library would not get.

One package became two, and only one of them has install instructions

The top dated entry in the documentation announces a split. As of version 0.9.0, published as two separate packages on the index: the first inherits the name tensorflow-privacy and holds the parts related to training models with differential privacy, and the second, tensorflow-empirical-privacy, holds the parts related to testing for empirical privacy. The repository reflects the split, holding both a setup file for the training package and a second setup file for the empirical one. The installation section does not. It offers a single pip command for the training package and then the clone and editable install path, and never mentions the empirical package by name outside that dated note. So the note that announces a second distribution channel is the only place it appears, and a reader arriving at the install section has no way to learn from it that the accounting and testing half now lives elsewhere.

Three one-line descriptions, two copyright lines, and a version read by exec

The package is described three different ways across two files. The repository summary calls it a library for training machine learning models with privacy for training data. The packaging file's short description calls it a privacy-focused machine learning framework. Its long description, which is what the index page actually renders, is a single sentence about implementations of TensorFlow optimizers, and it is registered as plain text rather than as the markup the documentation is written in. So the rendered description is the narrowest of the three and none of them is the text a reader would find by following the repository link. The copyright information is inconsistent in the same breath: the documentation closes with a 2019 Google LLC line while the packaging file opens with a 2018 TensorFlow Authors header, and that header points its licence at an unencrypted address. The version is also not written down. The packaging file reads it by executing the contents of a separate version file and pulling the value out of the resulting namespace.

The newest tag is from February 2024 and the updates section stopped there too

The three most recent tags are 0.9.0 published 2024-02-14, 0.8.12 on 2023-10-10 and 0.8.11 on 2023-10-05. The last commit to the default branch is dated 2026-08-26. So the branch has been worked on for roughly two and a half years since the last release, and a user installing from the index gets code that old while the branch is far ahead. The dated section at the top of the documentation, which is the closest thing to a changelog, has not moved with it: its newest entry is the 2024-02-14 note about the package split, and the one before it is 2023-02-21, describing a faster per-example gradient clipping implementation for models built only from dense and embedding layers, with a pointer to the paper it uses. The two releases from October 2023 appear nowhere in that list, so the section records selected announcements rather than releases. Anyone trying to work out what has changed since 0.9.0 has to read commit history instead.

The repository declares three tiers of stability and refuses submodules

The tree contains a library package, a tutorials folder and a research folder, and the documentation assigns each a different level of commitment. The library is the product. The tutorials are described as maintained carefully, with a walkthrough that teaches how to wrap existing optimizers into differentially private counterparts and how to tune the parameters and measure the guarantee, but they carry an explicit warning that they are not part of the API, can change at any time without warning, and that third party code importing them should not expect the interface to hold. The research folder is a different tier again, described as code to reproduce results from research papers, not maintained as carefully as the tutorials and intended as a convenient archive. Two other conventions are worth noting for anyone contributing. Code is expected in a particular style, with an autopep8 invocation suggested for the two-space indent and a pylint run against TensorFlow's own configuration. And pull requests that add git submodules are declined outright, with a link explaining the maintenance problems that motivated the rule.

A Bazel build and a pip build share the root, and only pip is documented

The root of this repository contains both a Bazel configuration and a Python packaging configuration. A bazelrc, a BUILD file and a WORKSPACE file sit alongside two setup files, a requirements file, and a pip_tools directory, which is the companion project for the compatible release policy the requirements file documents. The workspace file is the older Bazel workspace mechanism rather than the newer module definition, so the build predates the current default. None of the Bazel side is described in the documentation, which covers only the pip route end to end:

git clone https://github.com/tensorflow/privacy

followed by an editable install into the local path. That is a reasonable scope for a README aimed at users of the published packages, but it does mean a contributor has to discover the Bazel entry point by reading the build files. The tree also carries a g3doc directory, which is the convention for design documents in the TensorFlow family, and the documentation ends by pointing out that the content of this repository supersedes a differential privacy folder in the models repository, which is a useful warning for anyone who finds the older path and assumes it is current.

Editorial conclusion

TensorFlow Privacy suits a team that has pinned an older TensorFlow and an older Python and wants a differentially private optimizer with the analysis tooling to state what guarantee it actually delivered, since the two are designed to be used together rather than separately. It does not suit anyone starting fresh on a current Python, because the manifest excludes 3.12 and above, and it does not suit a reader who took the documentation's word for the dependency range, because the prose states a lower bound with no upper bound at all. Before installing, read the manifest rather than the install page and check both ceilings. If you intend to publish code that imports the tutorials, do not, because the project says explicitly that they are not API. And if you are evaluating the project on the basis of recent work, note that the newest tag is from February 2024 even though the branch has been committed to since.

Frequently asked questions

Official sources

1. Issues
2. License: Apache-2.0
3. README
4. Releases
5. tensorflow/privacy on GitHub