Keras project moved to new repository in

Dear Keras users:

We’ve spent a lot of effort making TensorFlow more modular and optimizing the dependency surface between Keras and TensorFlow. One of the milestones we’ve reached is that Keras code is being split to its own repository, (more details about the move can be found in the RFC). This enables Keras to use the Tensorflow Python API as a PIP package dependency without having to compile TensorFlow when building and testing. One of the biggest benefits of this change is that running Keras Bazel tests locally now only takes a few minutes, instead of several hours (mostly spent compiling Tensorflow).

With this change, the current code under the TensorFlow directory tensorflow/python/keras will become a stale copy and will soon be removed. Here’s what this means for you:

  1. Any new Keras PR or issue should be open in, instead of Keras development is fully moving to

  2. Any previously outstanding active Keras-related PR in will be merged manually into after approval (Keras team members will do the sync and merge internally, no action needed on the author’s side). However, if the PR has been open for a long time and lacks activity from the author, we may simply close it.

  3. Any previously outstanding active Keras-related issue in will be handled in the existing ticket thread, and will be fixed via commits to

  4. Stale Keras-related issues in will be closed. If still relevant, feel free to reopen the issue in instead.

  5. Any previously outstanding PR/issue in is stale and will be closed.

For more information, please take a look at the Keras contribution guidelines.

We hope these changes will provide a better user experience for developers and contributors of TensorFlow and Keras.


Scott Zhu, on behalf of the Keras team.


What is the process when we need to extend TF to extend Keras?

How we will handle the double PR and double review process (or in complex cases a double RFC)?

1 Like

If both TF and Keras need to be updated, the PR need to be split into two and submit separately. The RFC has a section to describe this community/ at master · tensorflow/community · GitHub.

We hope this is not a common case, since Keras is actually on top of Tensorflow, and based on change history internally, we don’t observe this case a lot.

1 Like

Yes it seems only 18.5%. Is this related to PR (so to user contribution) or to internal commits?

As I suppose that some features internally could be exposed in Tensorflow and not also to Keras in the same commit.

Anyway, in the end, beyond what the actual estimate of cases is, let’s try to manage them as best we can because it might be a criticality point since Keras is again a python-only standalone respository now.

E.g. Just like when you need to introduce an Op or a layer that you cannot solve efficetntly with a TF API compositional approach.

1 Like

This is same for both internal commit and external PR. Internally we do test against PIP package as well, which means a change can’t reach TF and Keras at same time.

We understand that any change that touch both TF and Keras could be hard to manage, and we will try our best to push forward those changes if it depends on the change in the other repo.


In the meantime how the new Keras tickets in TF are triaged (and vice versa)?
As we are in two different GitHub org I think that we cannot move the ticket across repos.

E.g. I think this Is the first one

1 Like

Both tickets in tensorflow/tensorflow and keras-team/keras will be looked at. Going forward we recommend opening tickets in keras-team/keras.


Thank God. :relieved:
However, as you quote

With this change, the current code under[ the TensorFlow directory tensorflow/python/keras will become a stale copy and will soon be removed.

So, after this change, we should do as

import keras

# but not as 
from tensorflow import keras

I don’t think so as that the API golden path is still tensorflow.keras. So formally, if I am not wrong, Keras is still an API in the tensorflow namespace:

Probably what it is interesting is to know if this API in the TF namespace will be under an independent Governance with:

Or if major changes will go through the RFC community process as TF and other SIGs:


Sorry for the late reply.

User should always use “from tensorflow import keras” which will give them the public API.

“import keras” will directly access the keras PIP package, which is not 100% same as the public API namespace. It will probably give you keras.Model/layers.* etc, but not all the APIs. Under the hood, we populate all the APIs under keras/api/* and tensorflow init files will pick them up from there.

See for more details.

1 Like