-
Notifications
You must be signed in to change notification settings - Fork 197
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
python-can 4.4.0 breaks canopen 2.2.0 #455
Comments
It's a known issue and already fixed on master. We just haven't got around to making a new release yet. |
See #422. |
This issue is intentionally kept open until the upcoming v2.3.0 release is out, so other users with the same problem can find it quickly. |
Note that hardbyte/python-can#1795 is already merged and will avoid this pitfall. Dunno when that will land in a release on PyPI though, so we should still try to fix it soon on our end. @christiansandberg I could make a release pretty soon, do I have your approval? Not sure what needs to be done beyond the GitHub release though, will it land on PyPI automatically? |
@acolomb go ahead and make a release if possible. It's nice to see so much activity but I haven't had the time to check all changes. I hope it should automatically push to pypi but if not I can do it manually. |
Alrighty, PyPI now has version 2.3.0, but Read The Docs hasn't picked it up yet. Noted a small mistake just after the release: README still stated Python >=3.6 support, but that is now fixed on master at least. The release notes do mention the upped dependency. |
CANopen automaticall gets the latest python-can 4.4.0 wich gives error:
TypeError: Can't instantiate abstract class MessageListener without an implementation for abstract method 'stop'
Reveting back to python-can 4.3.1 fixes issue
The text was updated successfully, but these errors were encountered: