subversion-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Daniel Shahaf <>
Subject Re: [PATCH] More bindings for gnome_keyring / platform_specific_client_providers
Date Wed, 08 Feb 2012 18:49:40 GMT
Matthijs Kooijman wrote on Wed, Feb 08, 2012 at 18:49:44 +0100:
> > >> So, you are saying that there is no legitimate/supported scenario in
> > >> which the .py and .so are out of sync with each other? 
> I can't provide anything authorative on that, other than that
> "make install-swig-py" seems to install them together and that I can't
> think of any legitimate scenario right now.
> Just in case, I just checked the scenario where the .py and .so would
> get out of sync (just in case). If the .so is old and the .py is new,
> then an AttributeError occurs in If it's the other way around,
> there will be an AttributeError in the user's code.
> There is another interesting case: If and
> get out of sync, one can get a linker error:
>     ImportError: /usr/local/subversion/lib/svn-python/libsvn/ undefined symbol:
> However, this is again nicely wrapped in a Python Exception, so no
> segfaults involved.

Thanks for the research.  It appears that the effect will be an ImportError
if mismatches, and an AttributeError otherwise.
(Does this mean that we need to have run-time version checks in ---
like the various svn_*_version() functions do?)

I don't know whether there's a valid scenario in which these two .so's will

But I also think the more important question to answer is the one from my
previous mail --- where in principle does the "is backportable?" line pass
for the bindings (like the feature/bugfix distinction in the core
libraries), and on what side on it does adding the unlock_prompt_func fall.

Thanks again,


> > >> 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?
> If the libsvn version is old, but the svn-python version is new, it will
> just work. If the svn-python is old, it will just throw an Attribute
> error (in the user's code).
> > >> (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.)
> The hasattr checks the existince in
> > 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)
> I guess having this check is good practice anyway because it:
>  1) Allows the code to work on platforms without gnome-keyring
>  2) Allows the code to work on older subversion versions without loss of
>     essential functionality.
> I guess point 2) is cheating somewhat, though.

View raw message