TensorFlow 2.12.0 depends on an older Numpy version than TensorFlow 2.11 does
Numpy was pinned to <1.24 since it affected few tests on Ragged Tensors.  Agree that we should fix those tests and remove the upperbound in future releases. @Dobiasd ,

Thanks for bringing this. The dependencies are already mentioned in `setup.py` file under `REQUIRED_PACKAGES` [here](https://github.com/tensorflow/tensorflow/blob/master/tensorflow/tools/pip_package/setup.py) which has to be followed for now. It might be missed in release notes. But this `setup.py` file is upto date and correctly listed the dependencies

The latest TF versions might not be compatible for the mentioned reason in above [comment](https://github.com/tensorflow/tensorflow/issues/60216#issuecomment-1496598836) and we hope the issue will be resolved soon.

Thanks!



 Ok, thanks! :+1:

It would be cool to eliminate this upper bound for the dependency version since any such upper bounds can be annoying. @Dobiasd ,

The upper bound is due to the reason mentioned above and definitely will be resolved at earliest possible.

Meanwhile if there is any functionality that affected by this limitation, please let us know.It may help us and provides more context for prioritising. Thanks ! Yes, I understood. Thanks. 👍 @Dobiasd ,

Do you want this issue to be open till the upper bound is removed? The reason for this limit has been mentioned in [comment-1496598836](https://github.com/tensorflow/tensorflow/issues/60216#issuecomment-1496598836) and likely to be resolved in Future releases.For current versions required numpy version are mentioned in seyup.py as you aware already.

Please confirm. Thanks!
 Thanks for asking! :heart:

Since I learned, the upper bound is not an oversight but intended, and since you're aware, I don't care if we keep this issue open or close it. Do with it whatever makes it simpler for you organization-wise. :relaxed: Please, keep this issue opened till the upper bound is removed.
Can we hope this will be soon by the way ? Will be fixed in 2.13.0 release. Can you give an approximative target date for release 2.13 (may be an rc release) ? Branch was cut last week, so RC0 should arrive soon. It used to be that RC0 arrived in at most 2 days after branch cut but now there are some delays. [RC0 wheels are now published](https://pypi.org/project/tensorflow/2.13.0rc0/#files) Hi @Dobiad,

Now the Upper bound on numpy version is removed in r2.13 version.Please refer the source code [here](https://github.com/tensorflow/tensorflow/blob/525da8a93eca846e32e5c41eddc0496b25a2ef5b/tensorflow/tools/pip_package/setup.py#LL93C1).

Also please refer the [gist](https://colab.research.google.com/gist/SuryanarayanaY/e45e1bfa8b05dbbea1e35fd8c641b1f4/60216.ipynb) which downloads numpy version -1.24.2 when installing `tensorflow==2.13.0rc0`.

Please spare some time in closing the issue as it is resolved now. Thanks! Thanks a lot; not only for the fix, but also for these great explanations! :heart: Are you satisfied with the resolution of your issue?
<a href="https://docs.google.com/forms/d/e/1FAIpQLSfaP12TRhd9xSxjXZjcZFNXPGk4kc1-qMdv3gc6bEP90vY1ew/viewform?entry.85265664=Yes&entry.2137816233=https://github.com/tensorflow/tensorflow/issues/60216">Yes</a>
<a href="https://docs.google.com/forms/d/e/1FAIpQLSfaP12TRhd9xSxjXZjcZFNXPGk4kc1-qMdv3gc6bEP90vY1ew/viewform?entry.85265664=No&entry.2137816233=https://github.com/tensorflow/tensorflow/issues/60216">No</a>
 > [RC0 wheels are now published](https://pypi.org/project/tensorflow/2.13.0rc0/#files)

Fyi, @mihaimaruseac 

I've installed this 2.13.0r0 with Python 3.10 for transformers and got error and rolling back to 2.12. 

```
Successfully installed keras-2.13.1rc0 tensorboard-2.13.0 tensorflow-2.13.0rc0 tensorflow-estimator-2.13.0rc0

ile "<frozen importlib._bootstrap>", line 1050, in _gcd_import
  File "<frozen importlib._bootstrap>", line 1027, in _find_and_load
  File "<frozen importlib._bootstrap>", line 1006, in _find_and_load_unlocked
  File "<frozen importlib._bootstrap>", line 688, in _load_unlocked
  File "<frozen importlib._bootstrap_external>", line 883, in exec_module
  File "<frozen importlib._bootstrap>", line 241, in _call_with_frames_removed
  File "/home/dev/anaconda3/lib/python3.10/site-packages/transformers/models/distilbert/modeling_tf_distilbert.py", line 34, in <module>
    from ...modeling_tf_utils import (
  File "/home/x/anaconda3/lib/python3.10/site-packages/transformers/modeling_tf_utils.py", line 70, in <module>
    from keras.engine import data_adapter

ModuleNotFoundError: No module named 'keras.engine'

RuntimeError: Failed to import transformers.models.distilbert.modeling_tf_distilbert because of the following error (look up to see its traceback):
No module named 'keras.engine'
```
Maybe because transformers from huggingface haven't update with this rc version. The problem still exists with TensorFlow 2.13.0:

```bash
pip install tensorflow==2.13.0 numpy==1.25.1 
```

```
ERROR: Cannot install numpy==1.25.1 and tensorflow==2.13.0 because these package versions have conflicting dependencies.

The conflict is caused by:
    The user requested numpy==1.25.1
    tensorflow 2.13.0 depends on numpy<=1.24.3 and >=1.22

```

@SuryanarayanaY So it seems the upper bound has not been removed. :confused: There was no upper bound for numpy with tensorflow 2.11 but it didn't mean that tensorflow 2.11 is working fine with numpy 1.24 or numpy 1.25,  which were not released when tensorflow 2.11 was released. May be there should have been an upper bound limit for numpy in tensorflow 2.11 !
I think you can't ask for a given tensorflow release to be by default compatible with all numpy releases in the future (they could have breaking changes needing changes in tensorflow...). So it's not abnormal to have an upper bound limit for numpy in tensorflow : it just means that more recent numpy releases (if any) have not been tested yet against tensorflow.

I think this issue should be closed and another one opened asking for tensorflow compatibility with numpy 1.25 (which is only one month old by the way)

I hope the next release of tensorflow (2.13.1 or 2.14.0) will accept numpy 1.25 (but maybe not numpy 1.26 !) Of course another possibilioty is to remove all upper bound limits and let tensorflow users open issues saying "Hi, I tried to use tensorflow 2.13 with last numpy 1.25.1, I encountered this problem...". 

Two different ways to deal with compatibily/dependency issues...  Thanks for the explanation. :+1:

However, I understood [this comment](https://github.com/tensorflow/tensorflow/issues/60216#issuecomment-1545394985)

> Now the Upper bound on numpy version is removed in r2.13 version.

such that the upper bound will be removed completely; maybe only pinning the major version (`numpy<2`), not the minor one.

But if we believe, numpy will introduce incompatibilities in a minor version change, then it might be unsafe, I agree.

So, I guess the question is: "Do we trust the numpy devs to version correctly, i.e., bump the major version on breaking changes?" I looked numpy changelogs. There are at least expired deprecations between minor versions.

But I'm just a tensorflow user. So don't take my comments as if they were from the tensorflow team and let them answer about the upper bound on numpy. Hi @Dobiasd ,

At present TF2.13v setup.py indicates numpy should be 'numpy >= 1.22, <= 1.24.3' as below. Since there would be always some delay in testing TF with latest numpy compatibilities. Engineering team was proactive in that and now we can see there is upper bound for numpy version with TF2.13v.If there would have been no upper bound then that should be addressed which is not the case now.

https://github.com/tensorflow/tensorflow/blob/1cb1a030a62b169d90d34c747ab9b09f332bf905/tensorflow/tools/pip_package/setup.py#L93

Currently Master branch has no upper bound on numpy as mentioned below and its working fine with tf-nightly as per attached [gist](https://colab.sandbox.google.com/gist/SuryanarayanaY/e81cf3451f81a8260907c32e5bfc3a9f/60216.ipynb). 

https://github.com/tensorflow/tensorflow/blob/9d6a57027317e673b4d0fea6372fe3aa69cb2714/tensorflow/tools/pip_package/setup.py#L93

Since this is continuous integration process and there will be always need for changes like this. I hope you also agree to that. We need to refer the latest commit always. Thanks for understanding.
 Thanks for the explanation. So if I understand correctly, the current `master` branch version does not have an upper bound for the NumPy version, but that does not mean that the next official release will also not have one. I.e., the upper bound for NumPy might be re-introduced again at some point, right? @Dobiasd ,

Yes you are right. There may be a chance that the upper versions has to be capped if there are compatibility issues(which we are not sure in advance) with latest versions.  This issue is stale because it has been open for 7 days with no activity. It will be closed if no further activity occurs. Thank you. This issue was closed because it has been inactive for 7 days since being marked as stale. Please reopen if you'd like to work on this further. Are you satisfied with the resolution of your issue?
<a href="https://docs.google.com/forms/d/e/1FAIpQLSfaP12TRhd9xSxjXZjcZFNXPGk4kc1-qMdv3gc6bEP90vY1ew/viewform?entry.85265664=Yes&entry.2137816233=https://github.com/tensorflow/tensorflow/issues/60216">Yes</a>
<a href="https://docs.google.com/forms/d/e/1FAIpQLSfaP12TRhd9xSxjXZjcZFNXPGk4kc1-qMdv3gc6bEP90vY1ew/viewform?entry.85265664=No&entry.2137816233=https://github.com/tensorflow/tensorflow/issues/60216">No</a>
 Just to add my 2 cents, the common practice in python, and the recommended one by core python and pypa developers, is to use upper bounds, and, at least in most (well-designed) libraries, on the major version. I think the reason is that if a minor version update of a _dependency_ (say numpy) breaks compatibility, the end user can simply downgrade that dependency version himself. But if tensorflow fixes the numpy dependency more strictly, it may simply not install into a given python environment, and the user can do absolutely nothing about it.
```bash
pip install tensorflow==2.11.1 numpy==1.24.2
```

works fine (as does `pip install tensorflow==2.11.0 numpy==1.24.2`).

But

```bash
pip install tensorflow==2.12.0 numpy==1.24.2
```

does not:

```
ERROR: Cannot install numpy==1.24.2 and tensorflow==2.12.0 because these package versions have conflicting dependencies.

The conflict is caused by:
    The user requested numpy==1.24.2
    tensorflow 2.12.0 depends on numpy<1.24 and >=1.22

To fix this you could try to:
1. loosen the range of package versions you've specified
2. remove package versions to allow pip attempt to solve the dependency conflict
```

To me, this looks unintended (I did not find anything in the documentation or release notes about it), so I've opened this issue. In case this behavior actually is intended (and not a bug in the dependency declarations), please just close the issue. (A remark in the docs would be cool though.)