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.
