Potential dependency conflicts between fklearn and numpy

[NeolithEra]

Hi, as shown in the following full dependency graph of fklearn, fklearn requires numpy >=1.16.4,<1.17.0, fklearn requires statsmodels >=0.9.0,<1 (statsmodels 0.11.1 will be installed, i.e., the newest version satisfying the version constraint), and directed dependency statsmodels 0.11.1 transitively introduces numpy >=1.14.

Obviously, there are multiple version constraints set for numpy in this project. However, according to pip's “first found wins” installation strategy, numpy 1.16.6 (i.e., the newest version satisfying constraint >=1.16.4,<1.17.0) is the actually installed version.

Although the first found package version numpy 1.16.6 just satisfies the later dependency constraint （numpy >=1.14), such installed version is very close to the upper bound of the version constraint of Numpy specified by statsmodels 0.11.1.

Once statsmodels upgrades，its newest version will be installed. Therefore, it will easily cause a dependency conflict (build failure), if the upgraded statsmodels version introduces a higher version of Numpy, violating its another version constraint >=1.16.4,<1.17.0.

According to the release history of statsmodels, it habitually upgrates Numpy in its recent releases. For instance, statsmodels v0.10.0rc1 upgrated Numpy’s constraint from >=1.09 to >=1.11 and statsmodels v0.11.0rc1 upgrated Numpy’s constraint from >=1.11 to >=1.14.

As such, it is a warm warning of a potential dependency conflict issue for fklearn.

Dependency tree

fklearn  - 1.18.0
| +- cloudpickle(install version:0.8.1 version range:>=0.8.0,<0.9.0)
| +- joblib(install version:0.13.2 version range:>=0.13.2,<0.14.0)
| +- numpy(install version:1.16.6 version range:>=1.16.4,<1.17.0)
| +- pandas(install version:0.24.2 version range:>=0.24.1,<0.25)
| +- scikit-learn(install version:0.21.3 version range:>=0.21.2,<0.22.0)
| +- statsmodels(install version:0.11.1 version range:>=0.9.0,<1)
| | +- numpy(install version:1.16.6 version range:>=1.14)
| | +- pandas(install version:0.24.2 version range:>=0.21)
| | +- patsy(install version:0.5.1 version range:>=0.5)
| | | +- numpy(install version:1.16.6 version range:>=1.4)
| | | +- six(install version:1.14.0 version range:*)
| | +- scipy(install version:1.2.3 version range:>=1.0)
| +- toolz(install version:0.10.0 version range:>=0.9.0,<1)

Thanks for your help.
Best,
Neolith

[NeolithEra]

Suggested Solution

1. Loosen the version range of numpy to be >=1.16.4.
2. Remove your direct dependency numpy, and use the numpy transitively introduced by statsmodels.
3. Change your direct dependency statsmodels to be >=0.9.0,<=0.11.1.
   @caique-lima Which solution do you prefer, 1 ,2or 3?
   Please let me know your choice. May I pull a request to solve this issue?

[mileo]

@NeolithEra i think that u tag me by mistake. Best regards!

[gcbeltramini]

@NeolithEra , thanks for the thorough report. Is this still an issue? I think that pip check should catch this, and the test that ran in the last PR was successful.

About your suggestions:

1. When using a bigger version range, we prefer to increase the upper bound. In this case, it could be numpy>=1.16.4,<1.18.0 or numpy>=1.16.4,<1.19.0 or numpy>=1.16.4,<1.20.0 (currently the latest numpy version is 1.19.5)
2. Since we use numpy directly, it's good to leave it in the requirements file. If I'm not mistaken, pandas started to suggest that you shouldn't import numpy from the pandas lib (e.g., from pandas.core.base import np).
3. Restricting statsmodels is a good option.