Inkscape, like many open source programs, uses Python as a scripting language for extensions. This is all fine and good, but unfortunately raises serious issues for binary distribution.
A few are obvious:
* Windows users don't have it * Mac users probably have an out of date version * Linux users almost certainly have it, but it's probably got a different ABI/API to what is expected
The first two do not concern me here. The last one does.
The libpython C API varies between systems in an incompatible manner. Python 2.2, 2.3 and 2.4 are all in the wild, and they export different APIs. Worse, Python can be configured to use either UCS2 or UCS4 unicode strings. The upstream default is UCS2 but some distributions configure it to use UCS4 - this changes the exported ABI.
I'm not sure what the solution to this is. Currently we recommend people do add Python for scripting to their applications, but that horse is long since gone for Inkscape. So we have a few alternatives:
1) Disable Python scripting in autopackage build. That'd be a shame. 2) Enable it in such a way that if libpython cannot be loaded, Inkscape still starts and works minus scripting 3) Figure out some new magic tricks so we can be compatible with all of them (relaytool can help here), for instance by avoiding the unstable parts of the API 4) Drop Python and port the scripts to some other system, like Lua or Mono
(3) is the best for the user but requires the most in-depth knowledge of the Python API and versioning history.
Statically linking Python isn't really an option, unfortunately.
thanks -mike