Reproducible output

[bk2204]

Right now, the XML output that's generated contains two different things that differ from invocation to invocation: the ID (due to the use of hash) and the timestamp. I like to diff my XML against the previous version to verify the changes, and this adds a lot of diff noise.

It would be great if we could have a way to produce reproducible output. I have a branch that replaces the invocation of hash with CRC32 and allows the user to set the SOURCE_DATE_EPOCH environment variable used in reproducible builds to get a fixed timestamp.

Assuming this is okay with you, I'd like to submit that branch, unless you're aware of a different way to go about it.

[mesozoic]

Sorry for the (very) delayed response! It is entirely my fault. This seems reasonable; feel free to send a pull request.

I'll admit that I don't use the XML workflow very often and I've even toyed with the idea of dropping support for it in 1.0 (to focus exclusively on managing filters via the API). It's helpful to know that someone out there still uses it.

[tom-henderson]

I also use the XML workflow, so I can review the changes before anything gets applied. I would love to see this feature added too.

[mesozoic]

I don't think the ID value actually has any meaning to Gmail, so we can probably test out any other value. I don't think I ever actually needed to use hash, I just didn't want to use a constant out of caution.

I also use the XML workflow, so I can review the changes before anything gets applied. I would love to see this feature added too.

I'd love to hear more feedback on what makes XML output more useful than --dry-run --sync via the API. It will help me think about where to take this project next and where to invest development time.

[bk2204]

In my case, I use it for diffing. Also, I'm carrying a patch which doesn't sort the entries because I have entries which check for a missing label, so order is important, and that doesn't work with the automatic syncing code.

[tom-henderson]

I'm very wary of anything having access to my email account. For me, if this tool had required API access I don't think I would have tried it in the first place.

[mesozoic]

That's a reasonable concern. For what it's worth, you store all your credentials locally and the application never requests more than the gmail.settings.basic and gmail.labels scopes. (Meaning the script can't read your email, set up new forwarding addresses, etc.) But I'm not planning to drop XML support right now.