Windows: Replacing Shipped Python Interpreter With Full (Extensible) Python

Previous topic - Next topic

jlpoole

I just placed this on the wiki:

http://wiki.scribus.net/canvas/Windows_Full_Python_Integration

For those of you who want the full panoply of Python's features available from within Scribus to make your Windows Scribus: Scribus on Steroids
John L. Poole

work: Principal Software Engineer, Oracle Corporation
play: Editions Poole - publisher of classical ensemble piano music (using InDesign & scripts thereunder)

a.l.e

well done!

i'm fine with that hack for now!

we are currently working on getting the new scripter to work (again) and i would love it, if you could get you involved and  provide a clean way to let the user choose any python interpreter from the preferences.

currently, we are in the phase of rebooting the (sub-)project but you can follow us on github:

https://github.com/aoloe/scribus-plugin-scripter

and already added a ticket

https://github.com/aoloe/scribus-plugin-scripter/issues/9

so that we don't forget to think about it.

for now we're struggling with replacing the outdated bridge between c++ and python (pythonize) and getting the signal/requests over from c++ to python... but your contribution will be really appreciated!

jlpoole

Quote from: a.l.e on June 16, 2015, 09:04:28 AM
... let the user choose any python interpreter from the preferences.

I would recommend against having a variety of Python interpreters and instead certify a particular version of Python for a given build of Scribus.  This is because you do not want to inherit bugs that may exist among the various Python builds and increase the chance that a problem arises because of a variance between Python builds, e.g. using 2.6 instead of 2.7.  I'm not that familiar with Python, but I am with Perl and I've seen enough discrepancies between builds in Perl that I would not want to add to the list of potential problems discrepancies that exists among Perl releases.  So, too, with Scribus and Python: if you limit support to Python 2.7 and releases thereafter, you will not have Scribus users who have versions less than 2.7 filing bugs that really arise because of their Python version difference.  And, given the dichotomy of Python 2.7 vs. 3.x already eroding stability in Python, I think it taking on too much risk to try to please everyone by accomodating various versions of Python.
John L. Poole

work: Principal Software Engineer, Oracle Corporation
play: Editions Poole - publisher of classical ensemble piano music (using InDesign & scripts thereunder)

a.l.e

you're right there.

but, at the same time, this is the way scripting works on linux (no python is included; the installed one is used). and nobody complained about compatibility problems.
it seems that it's less of a problem with python than with perl... or we don't use most of the advanced parts of python!

btw, i was not suggesting to drop the python dll, but to give a way in the GUI to define a different interpreter to be used. just like you're already suggesting in the wiki page you have created.
but instead of defining a path before starting scribus (which is rather cumbersome on windows) using the preferences (like we're alredy doing for gimp, latex and several other external tools)

of course, if one changes the path to use his own python, he must be ready to switch back if compatibility problems arise!

Kunda