Fixed ruamel version (not working with ruamel >=0.15.5)

[filicivi]

Ruamel 0.15.5 (released about 13 hours ago) not working correctly in conjunction with pykwalify.
With a default config, when borgmatic starts

pykwalify.errors.RuleError: <RuleError: error code 4: Value for keyword 'map/mapping' is not a dict: Path: '/'>

Installing ruamel.yaml==0.15.4 seem to solve the issue.

[witten]

Thanks for the PR. Looks like this issue was introduced by ruamel.yaml 0.15.52 specifically. ruamel.yaml 0.15.51 does not appear to exhibit this problem.

In doing some initial diagnosing with borgmatic, I looked at the type information of the ruamel.yaml-loaded schema before it's passed to pykwalify. With 0.15.51, it's a CommentedMap and is an instance of ordereddict. With 0.15.52, it's a CommentedMap but is not an instance of ordereddict. That's probably what's throwing off pykwalify.

Looking a the changelog, it definitely appears that this change occurred in 0.15.52.

I want to look at this a little more before just pinning to an older version as you suggest here.

[BarbzYHOOL]

Using borgmatic 1.2.0 would solve this issue?

Edit: yes

But if I keep my borgmatic on an older version, how can I keep borgbackup at a corresponding version (without manually compiling it)?

[witten]

@BarbzYHOOL borgmatic does not declare a pinned dependency on a particular version of borgbackup. Generally most versions of borgbackup should work with most versions of borgmatic.

Having said that, I plan to rectify this issue soon, so you won't need to pin borgmatic anymore.

[witten]

Okay, I believe this is now fixed in borgmatic 1.2.2, just released. Rather than pinning ruamel.yaml as in this PR, I managed to change borgmatic's use of ruamel.yaml to load the config and the schema in such a way that pykwalify no longer explodes. I confirmed that the changed code works with both ruamel.yaml 0.15.51 and 0.15.52 (before and after the breaking change, respectively).

I do appreciate the PR though. It let me know this was an issue, and it would've been the backup plan had I not been able to work around the issue.

[BarbzYHOOL]

"Generally most versions of borgbackup should work with most versions of borgmatic."

not true, I tried a simple setup the first time: borgbackup/stable 1.0.9-1 amd64 + borgmatic latest version (at the time, 1.2.0 I suppose), and it didn't work so I had to install the 1.6.1 borgbackup

And I confirm 1.2.2 works fine. Btw is there a command to display borgmatic version?

[witten]

Thanks for reporting that incompatibility. In the future, please feel free to file a ticket or submit a PR with a fix. Since borgmatic doesn't have an exhaustive matrix of continuous integration tests to validate compatibility with different versions of Borg (which would be pretty cool to have), I have to rely on bug reports for that.

[witten]

Also, do you recall what the incompatibility was with Borg 1.0.9? Was it with the --info sub-command argument ordering, or something else? A traceback/log would be super helpful.

[BarbzYHOOL]

I would reinstall the older borg to try but I am not sure how.

I tried to downgrade but it says:

 borgbackup : Depends: python3-llfuse (< 2.0) but it is not going to be installed
              Depends: python3-msgpack (>= 0.4.6~) but it is not going to be installed
              Depends: python3-pkg-resources but it is not going to be installed
              Depends: python3 (< 3.6) but it is not going to be installed
              Depends: python3 (>= 3.5~) but it is not going to be installed
              Depends: python3:any (>= 3.3.2-2~)
E: Unable to correct problems, you have held broken packages.

I think the incompatibility was simply not being able to launch borgmatic at all after installation.

[witten]

Okay, I'll see if I can reproduce the problem on my machine. If this sort of thing occurs again, a bug report would be great. Thanks.

[BarbzYHOOL]

Will do but well I needed to test borgmatic first before opening a bug report :P

[n3storm]

Okay, I believe this is now fixed in borgmatic 1.2.2, just released. Rather than pinning ruamel.yaml as in this PR, I managed to change borgmatic's use of ruamel.yaml to load the config and the schema in such a way that pykwalify no longer explodes. I confirmed that the changed code works with both ruamel.yaml 0.15.51 and 0.15.52 (before and after the breaking change, respectively).

I do appreciate the PR though. It let me know this was an issue, and it would've been the backup plan had I not been able to work around the issue.

Just installed borgmattic and got this error.

> pip3 show borgmatic
> Name: borgmatic
> Version: 1.2.2
> Summary: A wrapper script for Borg backup software that creates and prunes backups
> Home-page: https://torsion.org/borgmatic
> Author: Dan Helfman
> Author-email: witten@torsion.org
> License: UNKNOWN
> Location: /usr/local/lib/python3.5/dist-packages
> Requires: setuptools, ruamel.yaml, pykwalify

[n3storm]

This happens with ruamel.yaml 0.15.70. Moving to 0.15.69 solved this issue.

[witten]

Thanks for mentioning. This issue is being tracked here: https://projects.torsion.org/witten/borgmatic/issues/95 .. You're welcome to follow its progress there!

[n3storm]

sorry, thanks!

[witten]

No worries! Looks like the issue is now fixed in ruamel.yaml 0.15.71.