Re: [PATCH] More bindings for gnome_keyring / platform_specific_client_providers

Stefan Sperling <stsp_at_elego.de> writes:

> On Wed, Feb 08, 2012 at 07:01:48PM +0200, Daniel Shahaf wrote:
>> So, you are saying that there is no legitimate/supported scenario in
>> which the .py and .so are out of sync with each other? And that code
>> written for a library version that has the symbol will return a normal
>> error (eg, AttributeError in Python) when run against a library version
>> (such as 1.7.2) that doesn't have the symbol?
>>
>> (I'm talking about the .so here; it's not clear to me whether your
>> reference to hasattr() checked the existence of the symbol in the .py
>> library file or in the .so library file.)
>>
>> In these cases it seems to me that we might be able to backport this.
>> Stefan?
>
> I have no idea :)

I think the problem is that in Python one has to write:

  if hasattr(core, 'svn_auth_set_gnome_keyring_unlock_prompt_func'):
    core.svn_auth_set_gnome_keyring_unlock_prompt_func(ctx.auth_baton, prompt_func_gnome_keyring_prompt)

If called unconditionally:

  core.svn_auth_set_gnome_keyring_unlock_prompt_func(ctx.auth_baton, prompt_func_gnome_keyring_prompt)

it will work with 1.7.3 and fail with 1.7.2. In Ruby the magic is:

  if Svn::Ext::Core.respond_to?(:svn_auth_set_gnome_keyring_unlock_prompt_func)
    Svn::Ext::Core::svn_auth_set_gnome_keyring_unlock_prompt_func(ctx.auth_baton, gnome_keyring_prompt)

and I suppose Perl might have something similar.

I think that means this is not suitable for a backport.

-- 
uberSVN: Apache Subversion Made Easy
http://www.uberSVN.com