-
Notifications
You must be signed in to change notification settings - Fork 28
Check and update dependencies #87
Comments
but if we did that, wouldn't we be forcing installation of subprocess32 on py3 and async_timeout/aiohttp on py2? |
The above isn't a proposed list of dependencies to use, it's what I extracted from setup.py for easy pasting in the pyup online checker tool. |
ahhhh, i was thinking the idea was to commit that as a requirements.txt file, which we can't do because of the different requirements for python 2 and 3. Thanks! |
The breaking change made by `async_timeout` doesn't affect this project, since the only usage is with a non-zero timeout: https://github.com/aio-libs/async-timeout/blob/master/CHANGES.rst#200-2017-10-09 https://github.com/taskcluster/taskcluster-client.py/blob/888c98f8471ee4ce9ae4445353e99ef1560ec0c4/taskcluster/async/asyncutils.py#L39 Refs #87 (but doesn't close it, since there's more work to do).
Per this comment, we're thinking that:
it may be beneficial to stop pinning deps in |
Unpinning works for me :-) |
The problem is right now that there's a new version of slugid which is already not compatible with the current version specs of the client. If we just remove the pinning, instead of the knowledge that you need to use slugid <2 to avoid breaking this library being kept in this library, every single caller needs to keep that up to date. I'm happy to have Pyup keep track of dependencies for this repository. @escapewindow @edmorley are either of you able to help me set up pyup for this repository? |
Hm. I was in the loop for the slugid breaking change, and I use slugid in scriptworker, so I would possibly have noticed this sooner. I do think that if tc.py didn't pin, I'd blame the slugid breaking change rather than tc.py. However, we also update the client apis.json and associated methods on release. We'd benefit from regular tc.py releases anyway to keep the apis up to date.
Sure. I can add that to my list. |
To chip in, CiDuty can help with PyUp PRs once they are setup.
So adding a new PyUp PR to handle will not be an issue for us, as we usually are the first to know when deps/requirements fail to update. |
My current thoughts are in #130. |
Unpinned in #130. |
Continuing from:
90cdde8#commitcomment-25074883
I copied out the version lists from setup.py, trimmed the quotes and commas, which gives roughly:
And then pasted that in https://pyup.io/tools/requirements-checker/ , which shows updates for a few things.
It turns out there is an issue open for adding read-only setup.py support to pyup.io:
pyupio/pyup#137
And there's in fact a workaround suggested there for the moment:
pyupio/pyup#137 (comment)
The text was updated successfully, but these errors were encountered: