Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

chore: allow broader range of pandas versions #1364

Merged
merged 1 commit into from
Oct 21, 2023
Merged

chore: allow broader range of pandas versions #1364

Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
2 changes: 1 addition & 1 deletion setup.cfg
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -61,7 +61,7 @@ install_requires =
importlib_resources
numpy >=1.13
optlang ~=1.5
pandas ~=1.0
pandas >=1.0,<3.0
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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).

pydantic >=1.6
python-libsbml ~=5.19
rich >=8.0
Expand Down