Bug 1183377

It looks like python-dateutil broke backward compat in their rule._byweekday which break vobject

backtrace:
http://jenkins.cloud.fedoraproject.org/job/fedocal/456/console

reported upstream:
https://github.com/dateutil/dateutil/issues/24

I see you were going to work on the vobject side of this, pingou - any progress?

There has been some discussion on the vobject list, the project is basically looking for a new home and a new maintainer and might have found the later.

So no actual progress yet but I'm trying to keep up :)

Created attachment 993440 [details]
patch to change requires

What do you think about something like this for the interim, pingou?

Are you really considering changing the path to require the correct dateutils?

If we really wanted to go this route, I would suggest using something along the lines of:
https://github.com/fedora-infra/pkgdb2/blob/master/runserver.py#L4

But I still prefer to go the upstream route.

One more question, iirc, there are unit-tests for vobject so maybe we could use those instead of adding our own, no?

If I understand it correctly, changing the path is the most effective way to ensure that the desired, known good version of the module will be imported when the system has multiple versions available.  I'll happily defer to your judgment if there is a better way.

I'm not familiar enough with vobject to comment on unit tests, just suggesting an interim solution that should allow python-dateutil to be updated without breaking python-vobject.  I agree that an upstream solution would be best, and the only acceptable solution in the long term; for the short term, the patch is intended to allow python-vobject to persist as-is.

pingou: Do you means adding something like:
-__requires__ = 'vobject==0.8.1c'
+__requires__ = ['vobject==0.8.1c', 'python-dateutil == 1.5']

That should work, those binaries should get the right sys.path.

But I'm not sure if it'll work for dependent packages.
$ repoquery --whatrequires python-vobject
conduit-0:0.3.17-10.fc21.noarch
dexter-0:0.18-9.fc21.noarch
fedocal-0:0.5.1-4.fc21.noarch
openerp-0:6.1-8.20131111_004905.fc21.noarch
openerp7-0:7.0-6.20140109_002644.fc21.noarch
python-carddav-0:0.4.1-6.fc21.noarch
translate-toolkit-0:1.9.0-5.fc20.noarch
trytond-calendar-0:2.6.1-4.fc21.noarch
wuja-0:0.0.8-14.fc21.noarch

So #c4 seems like a safer option.

(In reply to Zbigniew Jędrzejewski-Szmek from comment #8)
> pingou: Do you means adding something like:
> -__requires__ = 'vobject==0.8.1c'
> +__requires__ = ['vobject==0.8.1c', 'python-dateutil == 1.5']
> 
> That should work, those binaries should get the right sys.path.

Yes that's what meant and this is likely the most elegant way to do it.

Yes, but does it work for, e.g. fedocal which does 'import vobject'?

I built python-dateutil with explicit Conflicts:python-vobject <= 0.8.1c-10 so that we can get some testing of the new dateutil. I hope you can build a new version of vobject soon.

Fixed in rawhide and f22