[texworks] Drop of Python scripting support

[Stefan Löffler]

Hi,

On 2011-11-01 00:40, Charlie Sharpsteen wrote:
> I've only done a brief once-over of the Python code and nothing jumped
> out as blatantly wrong. I will try to look at it more carefully when I
> get the time. I think QGIS embeds Python in manner similar to the way
> we do it and I know that Blender bundles its own Python interpreter
> into the Windows executable---so I am at a loss for explanations as to
> why what we do is "irresponsible" and produces a "monstrous exe".
>
> I certainly feel concern for the user who
> is experiencing problems---but without reproducible failures or
> an explanation of how we are using Python "irresponsibly" (Security
> risk? Incorrect method of packaging the interpreter with TeXworks?)
> there is nothing for us to improve. Also, I don't know if pulling
> Python support is the best fix for a situation that has not been
> demonstrated to exist.
>

The problem does not touch our code, it is about the way I build Windows
binaries and embed Python in there.
To quote from a subsequent email I received:

> You can hook a "TW object" to a Py_Object*. This is not
> the problem. The problem is to process, to run the Python
> script that contains this object. In order to do this,
> you need a Python engine and you need to distribute
> it, this Python engine requires a complete
> SxS assembly with manifest, VS libraries and so on to
> work on a win32 plaform. This is due to the MS VS 2008
> compiler Python is using since > 2.5. 

Since I'm cross-compiling the Windows binaries from Linux, I'm "stuck"
with MinGW (in particular, I'm using mingw-cross-env [1]). As I
understand it, the official policy is that Python for Windows should
(must?) be built using Microsoft Visual Studio (in particular, version
2008):
http://mail.python.org/pipermail/python-list/2010-April/1241719.html

Now, I cannot believe that this is carved in stone (in the sense that it
is impossible to build Python using MinGW), as Python is available on
the Mac and Linux. But at the same time, I'm not a Python crack (or even
a Windows internals specialist) - I'm just a Tw developer who read some
Python docs -, so I cannot say for certain (or foresee all problems that
may come with this).

The two possibilities I was offered are:
 - "distribute a more complete Python engine and let it run in some kind
of private environment." - with the addendum that doing it right is "a
very hard task and demand a large Python experience" (the former I'm not
interested in investing right now as there are other things occupying me
ATM, the latter I don't have)

 - "assume the end user has an installed correct version and your
application is using it." - now with the problem of the possibility of
conflicting Python installations, among others

I want to end with saying that in subsequent mails, the tone has changed
back to friendly - and I see no point in continuing to argue what was
said by whom. If someone has professional insights into this, I'd be
glad to continue here (which is why I shared some of the more technical
parts of the last mail I got), otherwise I consider the matter closed
for now.

> But that is your call as the packager for  Windows. If any important
> details come out, be sure to share them with me so I can adjust the
> Mac builds if necessary.

Sure, will do.

Stefan

PS: One additional technicality: as those of you using the Windows
builds probably have noticed (implicitly), mingw-cross-env uses static
building. That means no DLLs, everything is compiled in. Naturally, this
poses a problem with plugins (they're either in or out), which is
something I'd like resolved as well, but for now I have little hope of
accomplishing that goal. As a consequence, it is not possible to make
Python scripting support optional, it is either in or out, too.

[1] http://www.nongnu.org/mingw-cross-env/