Plea for mercurial_keyring to be pulled into tree

[Marcin Kasperski]

> Yes, indeed, every single keyring-generated password on the Mac is named 
> "Mercurial" which is not helpful at all.  This absolutely needs fixing 
> if mercurial_keyring is to be incorporated into Mercurial.

Current keyring library API allows one to specify "service", "username"
and "password" while storing the password. It is not completely clear
what the "service" is (*), but my general feeling is that it is some general
classification of password type. So I give "Mercurial" there.

And I miss some extra param which would let me specify sth more - say,
related url, or label, or anything.

   (*) this "service" is used differently among keyring backends. For
    example, in case of GNOME, it is used as (bare) domain name (with
    all other URL aspects remaining unset) while in case of KDE it is
    concatenated with username to serve as a key, and put in 'Python'
    folder.

Would keyring be extended to allow for one of those, it would be trivial
for mercurial_keyring to provide more detailed labelling (most likely, remote
repo url). But it is tough because keyring backend APIs are in general
fairly rich, but fairly inconsistent. 

For example, Gnome/seahorse is url oriented, the interface displays
plain list of URLs (mapping a password for every of them), and the API
  http://developer.gnome.org/gnome-keyring/stable/gnome-keyring-Network-Passwords.html#gnome-keyring-set-network-password-sync
is about setting protocol, domain, port, path, ...  Sth like a browser
saved passwords.

At the same time KDE KWallet uses folders hierarchy, where every folder
contains simple key->password mapping (and also sth called "maps" I do
not understand at the moment). The API fits this view
  http://api.kde.org/4.0-api/kdelibs-apidocs/kdeui/html/classKWallet_1_1Wallet.html#ad855eaa7974e230a5d26abb74fbbc89d

Finding a common abstraction which ensures some useful label is
preserved on both those is not that easy. Now add OS/X, Win and possible
future backends...

> The hgkeychain extension (which broke with recent Mercurial changes) did 
> a better job of naming; it depends on a pykeychain extension.  

Skipping keyring and using appropriate backends directly is of course
simpler but means having to support every sensible keyring separately
on the mercurial level. I do not fancy the idea too much, it would be
better to improve keyring (the library).