googledomains: Does not respect authentication configuration

[leamas]

The googledomains plugin in a bad state after merging #23 since it always uses .netrc, disregarding configuration of credentials source. I have patched the plugin in 66ba183 to cope with this.

@g2p : Have you any chance to review my patch?

[g2p]

Could the new auth plugins fix the limitation we had with netrc? Namely, the limitation of only being able to key on a hostname?
Both decisions discussed in #52 and #56, to mangle the hostname and copy-paste modified versions of auth functions, were because of following those limitations.
By introducing auth plugins, you have the opportunity to pass sufficient parameters to get_auth. The netrc plugin could go back to ignoring everything but the hostname.

Patch looks like it would work at a glance, but the design isn't evolving in a very directed way.

[leamas]

Anyhing is possible. However, one basic ramification is that get_netrc_auth will stay as it is -- I have declared a promise to stay API compatible up to 1.0.0.We could add a new method, though.

OTOH, backends are limited to a single key -> password mapping, so we need to apply tricks like those here to use a composite key. And netrc requires that the key at least resembles a dns hostname, I guess.

It's similar when it comes to the username/pw credentials, the keyring only maps a key -> password, so the username is stored together with the password.

In short, creating complicates schemas makes using different backends harder, I guess.

Going back to your problem here: Can you use plugin options to add hosts? Yes, you would need to handle the passwords manually, but this is now supported bu ddupdate -p. A standard configuration + some extra hosts proviced as plugin options -- shouldn't that make the trick?

but the design isn't evolving in a very directed way.

The direction is conservative, for sure. Trying to keep compatibility, that is.