deepyaman commented on PR #7376: URL: https://github.com/apache/iceberg/pull/7376#issuecomment-1518298511
> Setting upper bounds has a lot of problems for library code that is intended to be used by a lot of third parties. See also[ this blog](https://iscinumpy.dev/post/bound-version-constraints/) for a detailed discussion of the problems this creates. Tl;dr for some of the big points: > > It would be better to leave upper versions unbound by default, and to pin around broken versions if/when they are discovered. > > * Your library users can always manually drop down to a lower version of a dependency if they encounter an issue > * However, if you pin upper bound, users have no way of adopting a newer version of the dependency even if there is no actual incompatibility--they have to wait for you to release a new version without the pin. > * Since many of your dependencies are core members of the python data ecosystem, and given how long PRs tend to sit in this project currently, it's almost certain that you will be holding folks back from adopting the latest and greatest when e.g. pyarrow drops a new major version (happens every few months). > > There are many other important problems outlined in the blog post, but these above should be enough to argue convincingly for setting minimum versions only, and updating your pins when genuine incompatibility is discovered. @corleyma I largely (completely?) agree, and even referenced the same article in the issue I created for this. 😄 > There are very valid arguments against capping dependencies (see https://iscinumpy.dev/post/bound-version-constraints/ for a great post on the topic). However, even providing/relaxing the ranges would be a great start! But, as I also mention, it's a huge win to even relax them this significantly in my books. I figured a PR to relax upper bounds would be less contentious to start with. :) -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected] --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
