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:
>
> 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
#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.)
> 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
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?
> 4) 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@...
> https://lists.sourceforge.net/lists/listinfo/inkscape-devel
|
