On Tue, Nov 1, 2011 at 1:22 AM, Stefan Löffler <span dir="ltr"><<a href="mailto:st.loeffler@gmail.com" target="_blank">st.loeffler@gmail.com</a>></span> wrote:<div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">



<div>
> I certainly feel concern for the user who<br>
> is experiencing problems---but without reproducible failures or<br>
> an explanation of how we are using Python "irresponsibly" (Security<br>
> risk? Incorrect method of packaging the interpreter with TeXworks?)<br>
> there is nothing for us to improve. Also, I don't know if pulling<br>
> Python support is the best fix for a situation that has not been<br>
> demonstrated to exist.<br>
><br>
<br>
</div>The problem does not touch our code, it is about the way I build Windows<br>
binaries and embed Python in there.<br>
To quote from a subsequent email I received:<br>
<br>
> You can hook a "TW object" to a Py_Object*. This is not<br>
> the problem. The problem is to process, to run the Python<br>
> script that contains this object. In order to do this,<br>
> you need a Python engine and you need to distribute<br>
> it, this Python engine requires a complete<br>
> SxS assembly with manifest, VS libraries and so on to<br>
> work on a win32 plaform. This is due to the MS VS 2008<br>
> compiler Python is using since > 2.5.<br>
<br>
Since I'm cross-compiling the Windows binaries from Linux, I'm "stuck"<br>
with MinGW (in particular, I'm using mingw-cross-env [1]). As I<br>
understand it, the official policy is that Python for Windows should<br>
(must?) be built using Microsoft Visual Studio (in particular, version<br>
2008):<br>
<a href="http://mail.python.org/pipermail/python-list/2010-April/1241719.html" target="_blank">http://mail.python.org/pipermail/python-list/2010-April/1241719.html</a><br>
<br>
Now, I cannot believe that this is carved in stone (in the sense that it<br>
is impossible to build Python using MinGW), as Python is available on<br>
the Mac and Linux. But at the same time, I'm not a Python crack (or even<br>
a Windows internals specialist) - I'm just a Tw developer who read some<br>
Python docs -, so I cannot say for certain (or foresee all problems that<br>
may come with this).<br></blockquote><div><br></div><div><br></div><div>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 (<a href="http://tug.org/pipermail/texworks/2011q4/004933.html" target="_blank">http://tug.org/pipermail/texworks/2011q4/004933.html</a>).</div>


<div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
The two possibilities I was offered are:<br>
 - "distribute a more complete Python engine and let it run in some kind<br>
of private environment." - with the addendum that doing it right is "a<br>
very hard task and demand a large Python experience" (the former I'm not<br>
interested in investing right now as there are other things occupying me<br>
ATM, the latter I don't have)<br>
<br>
 - "assume the end user has an installed correct version and your<br>
application is using it." - now with the problem of the possibility of<br>
conflicting Python installations, among others<br></blockquote><div><br></div><div>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.</div>


<div><br></div><div>-Charlie</div></div>