mistercrunch commented on code in PR #28423:
URL: https://github.com/apache/superset/pull/28423#discussion_r1597121881
##########
pyproject.toml:
##########
@@ -85,7 +85,7 @@ dependencies = [
"shortid",
"sshtunnel>=0.4.0, <0.5",
"simplejson>=3.15.0",
- "slack_sdk>=3.19.0, <4",
+ "slack_sdk>=3.19.0",
Review Comment:
Let's talk about this! I wanted to start by noting that those boundaries are
used by raw "pip install apache-superset" (where having an upper bound is
probably a good idea, fully pinned for that use case might be an even better
approach...), and by @supersetbot to auto-generate PRs bumping pinned libs,
within the boundaries set here.
First question is what should happen when people in the wild just go `pip
install apache-superset`, all of our installation docs / docker / CI is pretty
clear about running the pinned dep installs first as in `pip install -r
requirements/base.txt` FIRST to get to something that's actually likely to
work. Now knowing that people may not do that, should we 1. pin stuff in the
package ? or 2. identify ranges of what's likely to work (kind of what we have
now with semver upper bounds). Note that the approach of "what's likely to
work" ranges is fairly subjective, and there's a fair amount of things that can
go wrong with this approach. Say if the `cryptography` lib has a major fix I
NEED in semver+1, the semver package upper bound restriction is actually
preventing me from getting what I need. All sorts of other non-pinned stuff can
still go wrong.
One thing is I think we need to differentiate semantics around real breaking
bounds (as in "we know library `>=N.x` won't work!") and hopeful ones (as in
"given what we know about semver, library > N.x could have breaking
changes...").
Anyhow, that's a complex topic, let's chat.
--
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: notifications-unsubscr...@superset.apache.org
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: notifications-unsubscr...@superset.apache.org
For additional commands, e-mail: notifications-h...@superset.apache.org
