Remove bound to numpy 1.24

[andrea-pasquale]

I was looking to update qibo to the latest version in qibocal but I saw that there was a dependency issue regarding numpy caused by the fact that in qibolab numpy was fixed to 1.24 when qibocal was supporting numba which is not the case anymore.

If needed I can also update qibo to the new release in this PR.

Checklist:

• [ ] Reviewers confirm new code works as expected.
• [ ] Tests are passing.
• [ ] Coverage does not decrease.
• [ ] Documentation is updated.

[codecov[bot]]

Codecov Report

All modified and coverable lines are covered by tests :white_check_mark:

Project coverage is 65.09%. Comparing base (53d6ea1) to head (47d1832).

Additional details and impacted files

```diff @@ Coverage Diff @@ ## main #833 +/- ## ======================================= Coverage 65.09% 65.09% ======================================= Files 50 50 Lines 6034 6034 ======================================= Hits 3928 3928 Misses 2106 2106 ``` | [Flag](https://app.codecov.io/gh/qiboteam/qibolab/pull/833/flags?src=pr&el=flags&utm_medium=referral&utm_source=github&utm_content=comment&utm_campaign=pr+comments&utm_term=qiboteam) | Coverage Δ | | |---|---|---| | [unittests](https://app.codecov.io/gh/qiboteam/qibolab/pull/833/flags?src=pr&el=flag&utm_medium=referral&utm_source=github&utm_content=comment&utm_campaign=pr+comments&utm_term=qiboteam) | `65.09% <ø> (ø)` | | Flags with carried forward coverage won't be shown. [Click here](https://docs.codecov.io/docs/carryforward-flags?utm_medium=referral&utm_source=github&utm_content=comment&utm_campaign=pr+comments&utm_term=qiboteam#carryforward-flags-in-the-pull-request-comment) to find out more.

:umbrella: View full report in Codecov by Sentry.
:loudspeaker: Have feedback on the report? Share it here.

[alecandido]

https://github.com/qiboteam/qibolab/commit/c67d18bf70c20c85d27c10d497570e8d57416236 https://github.com/qiboteam/qibolab/pull/631 https://github.com/qiboteam/qibolab/pull/630 https://github.com/qiboteam/qibocal/issues/457 https://github.com/qiboteam/qibocal/issues/457#issuecomment-1737444324

I'm not sure why @andrea-pasquale had to fix it, but it seems that NumPy 1.25 was being installed because of Qibolab (despite NumPy 1.24 was allowed after #630).

In any case, that's history. It is definitely not needed any longer.

In principle, I would have allowed a broader range for NumPy, just turning == in ^=, and keeping 1.24. But soon we will try to enable Python 3.12, and we will need NumPy 1.26 for that, so the current fix is good enough.

[andrea-pasquale]

Thanks for the reviews @stavros11 @alecandido.

I don’t understand why we were fixing the version in qibolab since numba was used by qibocal only and was never used qibolab (just trying to exclude any other reasons we may have fixed the version here, but I don’t think there are any).

The poetry.lock of qibocal was created correctly, the problem was that people were/are often using custom branches of qibolab and qibocal. Usually qibolab was installed after qibocal since it was a dependency of qibocal, therefore numpy will be overwritten without respecting the qibocal requirement.

[alecandido]

Usually qibolab was installed after qibocal since it was a dependency of qibocal, therefore numpy will be overwritten without respecting the qibocal requirement.

But if qibocal was fixing the NumPy version to 1.24 (i.e. ==), and qibolab allowed that version, in principle it should have not been overwritten.

This could only happen if you were installing with Poetry, and using the Qibolab lock file (that it might happen if you do pip install ., since then it will resolve the Poetry backend, but only if you explicitly installed qibocal first, and then manually pip install /path/to/qibolab/repo, more frequently cd /path/to/qibolab/repo; pip install .).

[andrea-pasquale]

But if qibocal was fixing the NumPy version to 1.24 (i.e. ==), and qibolab allowed that version, in principle it should have not been overwritten.

Yeah, indeed the version of NumPy in qibocal was not fixed by the pyproject.toml. It was fixed by the poetry.lock when finding a suitable configuration since numba was a requirement. So, I am not sure about was happening...