Skip to content
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

Doesn't work with python-click > 6.6 #198

Closed
rosshadden opened this issue Jan 10, 2017 · 6 comments
Closed

Doesn't work with python-click > 6.6 #198

rosshadden opened this issue Jan 10, 2017 · 6 comments
Assignees
Labels
bug

Comments

@rosshadden
Copy link

@rosshadden rosshadden commented Jan 10, 2017

I get an error when trying to use tmuxp that makes me think it is requiring exactly click==6.6. My system has click 6.7.1.

Here is the error:

2017-01-10-10 07 45

@thebopshoobop
Copy link

@thebopshoobop thebopshoobop commented Jan 12, 2017

This error is fixed by this commit. You can fix this problem by manually editing your local requires.txt file, which if you're running Arch is here: /usr/lib/python3.6/site-packages/tmuxp-1.2.3-py3.6.egg-info/.

This is the second time this week that updated packages have caused tmuxp to stop working for me. I understand the utility of dependency pinning for development purposes and that tmuxp has a very short list of dependencies. However, the current situation is that whenever one of those dependencies is updated, no matter how trivial the update, tmuxp is broken until a matching update in tmuxp can propagate through to end users. Might it be less user-hostile to have the dependencies be >= instead of ==?

@rosshadden
Copy link
Author

@rosshadden rosshadden commented Jan 12, 2017

@thebopshoobop Thanks, that did indeed work. And I am running Arch, too :D.

I really do think it should be >=, but I'm kind of an outsider to the python package ecosystem, and not sure if they have good support for semver resolving.

@rosshadden
Copy link
Author

@rosshadden rosshadden commented Jan 12, 2017

Actually the fact that it's not even a semver version means no, at least in this case... I guess I meant it more generally than semver, as in I don't know if python packages have a good solution for managing dependency versions.

@tony tony added the bug label Jan 13, 2017
@tony tony self-assigned this Jan 13, 2017
@tony
Copy link
Member

@tony tony commented Jan 13, 2017

@rosshadden @thebopshoobop How is v1.2.4? Better? Give it a shot and let me know

pyup.io did lock packages, but I'm not sure if it affected the release or not, as it happened after 1.2.3 was already tagged...

@thebopshoobop
Copy link

@thebopshoobop thebopshoobop commented Jan 14, 2017

@tony v1.2.4 does indeed work just fine. Thanks for the speedy tag.
@rosshadden I've posted an updated PKGBUILD here, and I've flagged tmuxp out-of-date in the AUR.

@rosshadden
Copy link
Author

@rosshadden rosshadden commented Jan 14, 2017

@tony Yep, works great. Thank you!
@thebopshoobop Good thinking.

@rosshadden rosshadden closed this Jan 14, 2017
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
3 participants
You can’t perform that action at this time.