Fix numpy version constraints

[guillett]

When I update working environments without specifying explicit version but avoiding only major version change I get a broken environment with

ModuleNotFoundError: No module named 'numpy.typing'

since #990

Technical changes

Fix numpy version constraints

Can that be a patch version change to 35.3.8 that would be followed by #1010 that would also by a non major version change and that would untied the limit on numpy version ?

[bonjourmauko]

Hello @guillett ! Thanks for this fix proposal to #1009.

The reason we can't easily pin NumPy to 1.20.x is that it will render the library unusable for the teams working at Institut des Politiques Publiques and Assemblée Nationale in France, because the latest available version they have at the CASD environment is 1.18.1.

More generally, there's an ongoing discussion on how to properly handle dependency versions in #1010 (loose vd tight).

#1010 provides a fix to #1009 that is not a major change but a minor one.

Can that be a patch version change to 35.3.8 that would be followed by #1010 that would also by a non major version change and that would untied the limit on numpy version ?

You mean to integrate this pull request and later #1010 to loosen up the constraint?

[bonjourmauko]

There is also another point, which is why I removed the NumPy version pump from #1010 a couple of minutes ago:

• Up to know, we've only been checking whether new NumPy versions deprecate parts of their API publicly exposed by OpenFisca (that's how we chose between a major and a minor when bumping the upper-bound version of NumPy).

• In this case, we're dropping support for 10 NumPy versions. Similarly, we would have to check all those 10 versions API deprecations, and decide whether it is a minor or a major, and in the latter case provide a transitioning guide for users.

[guillett]

The reason we can't easily pin NumPy to 1.20.x is that it will render the library unusable for the teams working at Institut des Politiques Publiques and Assemblée Nationale in France, because the latest available version they have at the CASD environment is 1.18.1.

The library is already unusable for IPP as of 35.3.7 but works fine with 35.3.6

You mean to integrate this pull request and later #1010 to loosen up the constraint?

Yes

[bonjourmauko]

The library is already unusable for IPP as of 35.3.7 but works fine with 35.3.6

Yes! Thankfully the reason is already identified, tagged as a bug, and one possible solution is proposed in #1010.

Regarding NumPy upgrades: you can see in #758, #990 and #924, that even if a lot of precautions are taken, sometimes the unforeseeable happens anyway.

The difference is that now the library is unusable because of a bug. If we tighten the supported NumPy versions, we would also render the library potentially incompatible not just for IPP but for other users as well.

We cannot easily know who's relying on which NumPy's version —specially in their own code, but we can as suggested in #924 check if the parts of the NumPy's API exposed by this library have been deprecated or not, in order to warn users of potential problems they could find.

I have initially proposed in #1010 to actually contraint supported NumPy versions to the last four minors, but dropped it to propose that change in another specific pull request, as it would at a minimum be a minor change, and potentially a breaking change, when a bug fix is available as a patch.

For that reason, even if I agree that we should improve the way we ensure actual usability of the library with the dependencies as they are declared in the setup.py file, as developed in this comment, I believe it should not take precedence over an actual bug fix for #1009, because of the greater potential impact on users.

[bonjourmauko]

Thanks again @guillett for this contribution 😃

The issue rendering OpenFisca-Core unusable for users with NumPy < 1.20 was fixed in #1010 🎉

Also, I integrated the changes you propose here in #1015 but taking into account the impossibility for some users to upgrade to NumPy 1.20 just yet and ensuring compatibility of new versions by testing both lower and upper bound supported versions of NumPy. Please do not hesitate to take a look and tell me what do you think.

[benjello]

@maukoquiroga @guillett : shoud we close or merge this PR ?

[bonjourmauko]

Hello @benjello, for me this will be superseded once and if #1015 gets merged, but I let @guillett propose an eventual alternative path.

[MattiSG]

#1015 seems to need more discussion. This PR is small and seems to solve a real problem.

If there is no side-effect (I had understood that some users depended on older versions of numpy than 1.20), I'm strongly in favour of merging it. If and when #1015 gets merged indeed, these changes will be changed again, and that's fine 😊

[MattiSG]

Ok with the change from a technical standpoint. Tested locally with Country-Template and Extension-Template and all work.

Just unsure about potential consequences for reusers.
Considering the history of changing Numpy versions in #990, I'd be very reassured if some other reuser could confirm this is fine with them. However, I feel like approving this PR considering a reuser opened it initially.

[bonjourmauko]

Thanks @MattiSG, if I remembered correctly the @openfisca/france-contrib-ipp and the @openfisca/france-contrib-leximpact folks were locked on NumPy 1.17 (CASD).

[benoit-cty]

Thanks @MattiSG, if I remembered correctly the @openfisca/france-contrib-ipp and the @openfisca/france-contrib-leximpact folks were locked on NumPy 1.17 (CASD).

Hello, the CASD team could update the package if needed. They now deploy Anaconda with the Python version and packages we ask for.

[benjello]

@MattiSG @benoit-cty : the CASD team can update but it is very costly for the IPP team to update now a,d very risky.
So please check with @clallemand, @bfabre01 and @pzuldp before any strong move in that direction ...

[bfabre01]

@guillett @MattiSG @benoit-cty : I agree with @benjello . Currently, there are already strong moves through the harmonisation of legislation parameters in openfisca-france, which will ask for important adjustment on the repo taxipp. As we enter in a period a annual budget evaluation, we cannot support too much moves. And a change in the numpy version may have implications for the repo taxipp. I did not get the exact reason of this update, but unless it solves a blocking issue, I prefer the setup being stable.
For information, in taxipp, we currently use the 1.18 version.
cc @clallemand @pzuldp

[MattiSG]

Thanks for your inputs.

I'm a bit lost now. I understand that OpenFisca currently advertises being compatible with numpy >= 1.11, < 1.21, which enables users with an M1 processor, for example, to rely on 1.20, and reusers that build against an older version of numpy to use their own. If that requirement is accurate, I am not sure why this changeset is useful.

@guillett could we please have an update from you on whether this changeset would solve any problem for your team today?

@openfisca/france-contrib-ipp do you have any automated tests for “taxipp” that would enable us to check the compatibility with numpy 1.20?

[bfabre01]

@MattiSG : thanks for your answer. Unfortunately, we don't have such an automated test outside of CASD.

[bonjourmauko]

Thanks for your inputs.

I'm a bit lost now. I understand that OpenFisca currently advertises being compatible with numpy >= 1.11, < 1.21, which enables users with an M1 processor, for example, to rely on 1.20, and reusers that build against an older version of numpy to use their own. If that requirement is accurate, I am not sure why this changeset is useful.

I think this changeset is no longer useful as the context of it (#1009) has already been solved.

Also, since #1014, supported versions are numpy >= 1.18, < 1.21.

@guillett could we please have an update from you on whether this changeset would solve any problem for your team today?

@openfisca/france-contrib-ipp do you have any automated tests for “taxipp” that would enable us to check the compatibility with numpy 1.20?

More generally I hope with #1030 that we'll be able to do a matrix test of Python 3.7+ and Numpy 1.18+ so to help reusers give a more accurate guarantee of OpenFisca's actually supported versions. 😃

[benjello]

Speaking for @openfisca/france-contrib-ipp : our automatic test is broken but the blame is on us.
CASD constrains us to use python 3.7 and numpy 1.18.
cc @clallemand @bfabre01 @pzuldp

[MattiSG]

This PR has been advertised as superseded by #1014 and further refined by #1010. I believe that it having been open for over a year while having been made obsolete by other changesets is a sign that the “getting a broken environment” issue has been fixed 😉 I'll thus close this PR. Feel free to reopen if I it is still relevant!