-
-
Notifications
You must be signed in to change notification settings - Fork 159
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
Remove incorrect upper bound from pytz
dependency
#225
Conversation
Change the `pytz` dependency to use the `>=` operator rather than `^`, in order to allow installing newer versions. `pytz` uses calendar versioning rather than semantic versioning, so the `^` operator is meaningless there. Furthermore, since `pytz` version corresponds to the timezone data release, allowing the newest version is important to permit using up-to-date tzinfo.
Hmm, I don't seem to be able to reproduce these test failures. |
Hmm, rebasing seems to have helped (or rerunning). |
There was another PR included in v3.1.0 that fixed the tests. The latest version of babel changed format strings to use a non-breaking-space before PM/AM. So the test failures are confusing because there's no visible difference :) |
A fixed release containing this PR would be great. |
Also, please consider not pinning any upper versions - flask-babel is a library and it should be up to the application to pin its transitive dependencies. As an application developer I do not want to wait for a library release in order to update e.g. flask, even if everything might still be compatible! cc @davidism since you know some nice blog post links on this topic ;) |
When writing a library, you should only use lower bounds for install dependencies. This allows people writing applications to use a tool like pip-tools to pin their full dependency tree. If libraries use restrictive bounds unnecessarily, it makes it impossible to pin to newer versions without a new release, whereas lower bounds can always be pinned more specifically in the application to work around issues. You can review any of the following for more information about not relying on any particular semantics in version numbers, and avoiding creating version conflicts: |
A PR with these changes would be accepted. My city currently has no power and my area will likely not get power for several more days. I can accept a PR and make a release, but any code changes will have to wait until I can recharge a laptop. |
This was already a PR, am I missing something? |
@davidism I think the confusing part is that 'master' isn't up to date with the 3.1.0 branch - so folks trying to 'test with latest' are in fact getting an older version.... |
Thank you! |
Change the
pytz
dependency to use the>=
operator rather than^
, in order to allow installing newer versions.pytz
uses calendar versioning rather than semantic versioning, so the^
operator is meaningless there. Furthermore, sincepytz
version corresponds to the timezone data release, allowing the newest version is important to permit using up-to-date tzinfo.