subversion-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Daniel Shahaf <danie...@elego.de>
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 core.py. If it's the other way around,
> there will be an AttributeError in the user's code.
> 
> There is another interesting case: If _core.so and libsvn_swig_py-1.so
> get out of sync, one can get a linker error:
> 
>     ImportError: /usr/local/subversion/lib/svn-python/libsvn/_core.so: undefined symbol:
svn_swig_py_auth_gnome_keyring_unlock_prompt_func
> 
> 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 _core.so mismatches libsvn_swig_py-1.so, and an AttributeError otherwise.
(Does this mean that we need to have run-time version checks in _core.so ---
like the various svn_*_version() functions do?)

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

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,

Daniel

> > >> 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 core.py.
> 
> > 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.

Mime
View raw message