-
-
Notifications
You must be signed in to change notification settings - Fork 168
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
Add tornado<6.2
pin to distributed
#291
Add tornado<6.2
pin to distributed
#291
Conversation
Hi! This is the friendly automated conda-forge-linting service. I just wanted to let you know that I linted all conda-recipes in your PR ( |
Thanks James! 🙏 Can you please run |
Yeah, no problem show_diff.py output:
|
Thanks James! 🙏 Should we do something similar for packages using Edit: Thinking about that question, wonder if we should base this on a timestamp instead. IOW setting an upper bound for all |
Thanks @jakirkham, sorry for the delayed response. Are package dependencies merged? I.e. if we have
does that resolve to diff --git a/recipe/gen_patch_json.py b/recipe/gen_patch_json.py
index 74754d0..13a2992 100644
--- a/recipe/gen_patch_json.py
+++ b/recipe/gen_patch_json.py
@@ -621,9 +621,8 @@ def _gen_new_index_per_key(repodata, subdir, index_key):
# Older versions of distributed break with tornado 6.2.
# See https://github.com/dask/distributed/pull/6668 for more details.
v2022_6_1 = pkg_resources.parse_version('2022.6.1')
- if pversion < v2022_6_1 and 'tornado >=6.0.3' in record['depends']:
- i = record['depends'].index('tornado >=6.0.3')
- record['depends'][i] = 'tornado >=6.0.3,<6.2'
+ if pversion < v2022_6_1:
+ record['depends'].append('tornado <6.2')
if record_name == 'fastparquet':
# fastparquet >= 0.7.0 requires pandas >= 1.0.0 would do the trick. |
No worries. Yeah I think that would work |
Here's the
|
Thanks James! 🙏 |
@jrbourbeau @jakirkham Thanks for getting the patch in. Could you help me understand the rationale behind applying the As I understand from dask/distributed#6669, the issue with The reason I'm curious about this is that patches of this nature could break projects that make use of "frozen" environments (e.g., generated by Would love to get your thoughts on how downstream projects could alleviate the impact of upstream patches to conda-forge's index metadata. Thanks! |
Because if one of the old versions of Interesting I'm not sure I totally follow why that would be the case. Wouldn't old environment have preceded newer Tornado releases and not have this constraint? Or were those environments perhaps underspecified? Or was there some narrow window of versions where this comes up? |
Thanks for the quick reply, John! The problem I mentioned with frozen environments would manifest itself within a specific time window. I'll illustrate with a concrete example.
Any project that chose to freeze their environment between 7/4 and 7/26 would run into this issue when they subsequently tried to recreate their frozen environment. |
Was it intentional to leave 2022.6.1 installable with tornado 6.2? This PR added the pin for all before this one, but the pin was added to the recipe after that version. Tornado 6.2 is the only version of Tornado available for Python 3.11 in conda-forge, so I'm trying to figure out if I actually should be able to install |
^ Thoughts on Ryan's question above @jrbourbeau? |
Thanks for the ping @jakirkham -- apologies for such a delayed reply. @dopplershift is this still an issue for you? Python 3.11 support was only added in the latest |
Checklist
0
(if the version changed)conda-smithy
(Use the phrase@conda-forge-admin, please rerender
in a comment in this PR for automated rerendering)Applying the changes made in conda-forge/distributed-feedstock#211 to previous
distributed
releases.I think this should be the correct logic, but @jakirkham if you get a chance to take a quick look at this that would be welcome