> >> 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.
> >> 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.
In any case, I don't really know what the best course of action here is.
It seems backporting wouldn't cause any real problems, but I'm not
completely aware of the existing practices and policies within the
project...
Gr.
Matthijs
Received on 2012-02-08 18:50:21 CET