Skip to content

Remove upper limits from dependencies #63

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

Merged
LeoGrin merged 1 commit into from
Mar 9, 2026
Merged

Remove upper limits from dependencies #63

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
6 changes: 3 additions & 3 deletions pyproject.toml
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -21,10 +21,10 @@ classifiers = [
requires-python = ">=3.9"
dependencies = [
"numpy>=1.21.6",
"pandas>=1.4.0,<3",
"pandas>=1.4.0",
Copy link
Contributor

@gemini-code-assist gemini-code-assist bot Mar 9, 2026

Choose a reason for hiding this comment

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

high

While removing upper bounds can help with downstream dependency conflicts, completely removing the major version cap for pandas is risky. A future major version (e.g., v3.0 or v4.0) could introduce breaking changes that would cause tabpfn-common-utils to fail at runtime. A good compromise is to allow for the next major version while capping at the one after. This provides flexibility while still protecting against future breaking changes.

Suggested change
"pandas>=1.4.0",
"pandas>=1.4.0,<4",

"scikit-learn>=1.2.0",
"typing-extensions>=4.12,<5",
"posthog~=6.7",
"typing-extensions>=4.12",
"posthog>=6.7",
Copy link
Contributor

@gemini-code-assist gemini-code-assist bot Mar 9, 2026

Choose a reason for hiding this comment

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

high

Removing the upper version cap for posthog is risky. The previous specifier ~=6.7 was equivalent to >=6.7,<7, which protected against breaking changes in a future v7.0 release. By changing to >=6.7, the library becomes vulnerable to such breakages. It's recommended to keep an upper bound to ensure future compatibility.

As a side note, the PR description's claim that ~=6.7 pins to <6.8 is incorrect for a two-part version number; according to PEP 440, it pins to <7.

Suggested change
"posthog>=6.7",
"posthog>=6.7,<7",

"platformdirs>=4",
"filelock>=3.19.1",
"requests>=2.32.5",
Expand Down