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.

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

Update tensorflow-probability version range #107

Merged
merged 2 commits into from
Jan 13, 2025

Conversation

williamjamir
Copy link
Contributor

Loosening the requirements allows for the installation of the newer version 0.25 of tensorflow-probability, enabling the installation of tensorflow 2.18 and consequently numpy 2.0.

@williamjamir
Copy link
Contributor Author

Hi @WillianFuks!

Currently setup.py specifies upper version bounds for Pandas and Tensorflow-probilitistic.

IMHO, strict upper bounds can lead to dependency conflicts and make it harder for users to integrate the library with other packages. To improve compatibility and the overall developer experience, it might be helpful to remove these upper version constraints.

This blog post from Henry Schreiner (core maintenair of many scientific building packages) explains the drawbacks of tight version bounds in more detail.

What do you think about loosening these constraints, I can open a PR removing them if you agree :)

@WillianFuks
Copy link
Owner

Hi @williamjamir

I certainly agree with you, I tried avoiding setting upper bounds for quite a while but then each new release from dependencies that contained backwards incompatible changes kept breaking things up.

It became a problem of finding a balance between avoiding conflicts internally and also externally with the user`s own packages versions installed.

So the strategy taken, in a way, is to keep up-to-date with current releases while protecting the code against new breaking changes. Not sure if that was the best approach, it was what worked at the time.

I'll read your reference article, if there are any ideas on how to remove the upper bounds while avoiding having the code breaking unexpectedly I'm certainly in favor of doing that.

@WillianFuks WillianFuks merged commit 3688b83 into WillianFuks:master Jan 13, 2025
8 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants