On Fri, Nov 25, 2005 at 02:28:50PM +0000, Mike Hearn wrote:
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:
- Disable Python scripting in autopackage build. That'd be a shame.
- Enable it in such a way that if libpython cannot be loaded, Inkscape still starts and works minus scripting
#2 may be the best solution for now, as I imagine it'd be more straightforward to implement than #3, but would leave users with at least the hope of having Python. As aaron points out, while the build system permits linking against libpython, the scripting support in Inkscape is not hooked up to Inkscape's internals, so is not of any practical use anyway at current. (It's worth keeping though, since once the DOM work is in place, we'll be able to hook into that and suddenly have a great deal of power available to pythonites.)
- 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
Would 'shim layers' be of any use? I.e., separate bits of code that sit between Inkscape and libpython to compensate for ABI incompatibilities? You'd have three of these shims, one for each of the three libpython versions, that allow Inkscape to speek consistently to all.
Also, this sounds like a larger problem than just for Inkscape... aren't other Python-using applications running into similar issues? What approaches have they taken to work around it?
- Drop Python and port the scripts to some other system, like Lua or Mono
4 sounds like a pass the buck solution. ;-) I don't know anything about Lua or Mono but would imagine that there could just as conceivably be an ABI issue with them (unless they're taking special precautions against that...) Our initial vision was for Inkscape to be scripted with a variety of common scripting languages (Python, Perl, ...) to enable as wide a variety of people as possible to be able to contribute in ways they are both skillful and comfortable with. Of course, a balance is needed due to the fact that every new scripting language increases the challenge for packagers.
(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.
Agreed.
thanks -mike
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click _______________________________________________ Inkscape-devel mailing list Inkscape-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-devel