Upper limits on requirements

[NeoChaos12]

An upper limit on the requirements of various dependencies seems to be a very harsh constraint. Since most repositories tend to try and maintain backwards compatibility when releasing new versions, doing so only plays a role when major updates that break backwards-compatibility are made. Otherwise, this simply complicates setting up appropriate environments. It would thus be preferable to forego setting these upper limits unless issues have been reported.

[PhMueller]

I had problems with the pandas version in combination with the openml data loading for the xgboost or svm benchmark.

The data loading script from the benchmarks required an older OpenML version, which unfortunately requires an older pandas version (and doesn't work with the new ones.)

Have you tried it or found a fix for this issue?

[KEggensperger]

I would even recommend fixing the versions since we use these extra_requirements to also build the containers which should not change over time. What do you think?

[PhMueller]

It is beyond question the cleanest way. 😅. But maybe it is easier to handle this in a separate Pull Request?

[KEggensperger]

Yes, agreed. We should fix the dependencies (at least for building container) in a separate PR.

Regarding removing the upper limit on the pandas versionf for the local version: Since there might be issues with loading data from openml, let's wait for the next python openml release which is scheduled next week and re-discuss the dependencies then.

[NeoChaos12]

I have actually wanted to know for months if you actually encountered issues with the higher versions, since I've been using using python>=3.8.3 and higher pandas versions for a while. They go hand-in-hand, as there seem to be some dependency conflicts between the python and pandas versions as well. Let's wait for the openml update though.

Should we consider having a "developer" set of requirements that is more flexible but carries fewer guarantees?