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.
Received on 2012-02-08 19:50:22 CET