Bug 1288581 - Do NOT upgrade to pyudev 0.18
Do NOT upgrade to pyudev 0.18
Product: Fedora
Classification: Fedora
Component: python-pyudev (Show other bugs)
Unspecified Unspecified
unspecified Severity unspecified
: ---
: ---
Assigned To: David Shea
Fedora Extras Quality Assurance
: Reopened
Depends On:
  Show dependency treegraph
Reported: 2015-12-04 11:27 EST by Alan Pevec
Modified: 2015-12-11 12:56 EST (History)
5 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2015-12-11 12:56:32 EST
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description Alan Pevec 2015-12-04 11:27:32 EST
Release 0.18 included backward incompatible change which breaks one OpenStack component https://bugs.launchpad.net/ironic-python-agent/+bug/1522756

Issue was reported upstream:

While at it, would be nice to persuade upstream to switch to semver :)
Comment 1 David Shea 2015-12-04 11:36:58 EST
Don't do anything, you say? I'll get right on it ;-)

Thanks for the heads up.
Comment 2 Alan Pevec 2015-12-07 06:22:36 EST
> Don't do anything, you say?

Implicit message was: try to influence upstream :)
Comment 3 mulhern 2015-12-11 08:54:37 EST
But the change _is_ backwards compatible, as the original reporter has now figured out. See issue discussion: https://github.com/pyudev/pyudev/issues/129.
Comment 4 Dmitry Tantsur 2015-12-11 09:05:07 EST
The changes is not backward compatible. I know the work around now, yes, but it does not mean that working code won't break. It would be compatible only if new exception class was derived from old one, as I suggested initially.
Comment 5 mulhern 2015-12-11 11:03:04 EST
You have finally fixed a bug that has been in your code since you first started using the method from_device_file(). This method transitively invokes the method from_device_number() which may raise DeviceNotFoundByNumberError which is a subtype of DeviceNotFoundError. This error, if raised, is propagated and should be caught by any code that invokes from_device_file().

All you need to do is fix your code to catch DeviceNotFoundError, like you should have been doing all along.

If anything, this is an ironic_python_agent bug and should be treated as such.
Comment 6 Dmitry Tantsur 2015-12-11 11:53:09 EST
You're free to close this bug, if you don't care too much about other consumers of your library who might have hit by it, I won't reopen, but please stop assigning it to random projects. python-ironicclient is not involved here at all. And as you noted, IPA was fixed to work around the break.

Also this:

> All you need to do is fix your code to catch DeviceNotFoundError, like you should have been doing all along.

You code has never raised DeviceNotFoundError, we should NOT have caught it before the change. Again, feel free to close it, but don't blame others for your actions please.
Comment 7 mulhern 2015-12-11 12:56:32 EST
First, it is not my code, it is Sebastian Werner's, principally.

Second, that your tests haven't caused that exception to be raised just means that your tests are not complete enough. The code has always been capable of raising that error.

Third, except for a physics post-doc in Germany and one Red Hat employee who has contributed a bug fix the main thing my downstream consumers have contributed is insults. "Caring" does not come naturally to anybody in that situation, it's not a very "caring" environment.

Fourth, according to the document that you sent me: http://semver.org/,
"Major version zero (0.y.z) is for initial development. Anything may change at any time. The public API should not be considered stable." If you understand semantic versioning, then you understand that version 0.17 means that the API can change at any time. Any of the _hard_ work that I do to keep the API stable is not in any way an obligation by these semantic versioning standards which you claim I'm breaking.

Fifth, the only reason to keep the API stable is professional pride, consideration of clients, and the good of Red Hat, which pays my salary. Red Hat does not pay me to waste my time in this kind of pointless argument. I assume it doesn't pay you for that, either.

Note You need to log in before you can comment on or make changes to this bug.