chore: allow broader range of pandas versions #1364
Conversation
Midnighter
commented
Oct 19, 2023
Midnighter
commented
- fix upgrading dependency to allow pandas>=2.0 #1362
- description of feature/fix
- tests added/passed
- add an entry to the next release
| @@ -61,7 +61,7 @@ install_requires = | |||
| importlib_resources | |||
| numpy >=1.13 | |||
| optlang ~=1.5 | |||
| pandas ~=1.0 | |||
| pandas >=1.0,<3.0 | |||
There was a problem hiding this comment.
I do see the point of doing it this way, but I feel that for packages with as few maintainers as cobrapy maybe we should only limit max versions if we know for a fact that the new major version is incompatible with cobrapy code. Especially for pandas where the max version has broken things before. This is because a user can always downgrade pandas by hand if required but going above the max version is much harder for the user.
There was a problem hiding this comment.
Initially, I agreed with you, but then I thought back to past experiences and I'm less sure now. I would be okay with doing so for pandas who are very committed to maintaining a stable API, however, I don't think we should make it a general practice. For other packages like libSBML, I was even tempted to pin the version exactly, because upgrades caused us quite a lot of pain. What I'm trying to say, I think it's a quick and easy change to increase the version range at a time of our choosing, when we had time to test a new major version. It's a lot more work to handle issue reports and make fixes just when a dependency comes out with an update.
There was a problem hiding this comment.
Hmm makes sense as well and in your defense there were cases where the lack of constraints broke things (like numpy deprecating the internal types). In that case we should probably get better in fixing those things (I mean being quicker about it).
