[texworks] Drop of Python scripting support

[Charlie Sharpsteen]

On Tue, Nov 1, 2011 at 1:22 AM, Stefan Löffler <st.loeffler at gmail.com>wrote:

>  > 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).
>


I think these requirements only apply to Python distributions that are
built using Visual Studio---since you are cross-compiling using MinGW it
could be a moot point. The "private environment" could be as simple as
ensuring Python environment variables are set correctly---something we
discovered in the "Texworks quit working (on windows)" thread (
http://tug.org/pipermail/texworks/2011q4/004933.html).

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
>

Assuming an installed version of Python, say in '/c/Python27' would be
tricky as there could be issues between code compiled under MSVC and code
cross-compiled using MinGW. Plus, it is hard to know which version would be
installed and I know of at least three major distributions for Windows:
Python.org, EPD and PythonXY.

-Charlie
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://tug.org/pipermail/texworks/attachments/20111101/289a23a1/attachment.html>