<div dir="ltr">I did that once; it wasn't worth it. It was no smaller than what PyInstaller would output and required manually adding in the required modules that weren't in the stdlib, along with any extra DLLs (e.g. the Qt DLLs).<div><br></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Fri, May 29, 2015 at 4:45 PM, Paul Moore <span dir="ltr"><<a href="mailto:p.f.moore@gmail.com" target="_blank">p.f.moore@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="HOEnZb"><div class="h5">On 29 May 2015 at 21:49, Glenn Linderman <<a href="mailto:v%2Bpython@g.nevcal.com">v+python@g.nevcal.com</a>> wrote:<br>
><br>
> That looks interesting, I wonder what compilation environment it would need?<br>
> I don't think I've even installed a C compiler on my last couple boxes, and<br>
> the only version of a C compiler I have is, umm... M$VC++6.0, since I've<br>
> moved to using Python for anything a 5 line batch file can't do...<br>
><br>
>> One mildly annoying thing is that python3.dll is only installed in<br>
>> <python install dir>\DLLs, which typically isn't on PATH.<br>
><br>
> Ah, linking.... so I guess if I figured out how to create this binary, it<br>
> would contain a reference to python3.dll that would attempt to be resolved<br>
> via the PATH, from what you say, and typically fail, due to PATH seldom<br>
> containing python3.dll.  The python launcher gets around that by (1) being<br>
> installed in %windir%, and going and finding the appropriate Python (per its<br>
> own configuration file, and command line parameters), and setting up the<br>
> path to that Python, which, when executed, knows its own directory structure<br>
> and can thus find its own python3.dll.<br>
><br>
> The launcher, of course, adds an extra layer of process between the shell<br>
> and the program, because it launches the "real" Python executable.<br>
><br>
>> So actually using the limited API from your own application fails by<br>
>> default.<br>
>> Fixing that's mostly a user admin issue, though (and you can just link<br>
>> to the full API and avoid the whole problem).<br>
><br>
><br>
> Do I understand correctly that the "user admin issue" means "add the<br>
> appropriate <python install dir>\DLLs to the PATH"?<br>
><br>
> What I don't understand here is how linking to the full API avoids the<br>
> problem... it must put more python library code into the stub executable?<br>
> Enough to know how to search the registry to find the <python install dir><br>
> for the version of Python from which the full API was obtained? Or something<br>
> else?<br>
<br>
</div></div>Sorry, I assumed more Windows/C knowledge than you have.<br>
<br>
I'll work on this and produce proper binaries in due course, so you<br>
can always wait for them. But you can build the stub with pretty much<br>
anything, I suspect - I managed with MSVC 2010 and mingw. I'll add<br>
some build docs and get it on github.<br>
<br>
Using mingw<br>
<br>
    gcc -Wall -O2 -o stub.exe stub.c -I <python home>\Include<br>
C:\Windows\system32\python34.dll<br>
    strip -s stub.exe<br>
<br>
Using MSVC<br>
<br>
    cl /Festub.exe /O2 stub.c /I<python home>\Include <python<br>
home>\libs\python34.lib<br>
<br>
Regarding the DLLs, yes the "user admin issue" is adding the right<br>
directory to PATH. I used the phrase "admin issue" as it's the aspect<br>
that's likely to be far harder than any of the technical issues :-)<br>
The reason using the full API helps is that the full API references<br>
python34.dll rather than python3.dll. And the Python installer puts<br>
python34.dll on PATH automatically, as it's what the "python" command<br>
uses. (For the people with more Windows knowledge, I know this is a<br>
simplification, but it's close enough for now).<br>
<br>
So there are two  options with the code I posted.<br>
<br>
1. Build an exe that uses a specific version of Python, but which will<br>
"just work" in basically the same way that the "python" command works.<br>
2. Build an exe that works with any version of Python, but requires<br>
some setup from the user.<br>
<br>
Either approach requires that the Python DLL is on PATH, but that's<br>
far more likely with the version-specific one, just because of how the<br>
installer does things.<br>
<br>
With extra code, the stub could locate an appropriate Python DLL<br>
dynamically, which would simplify usage at the cost of a bit of fiddly<br>
code in the stub.<br>
<br>
This might be a useful addition to the zipapp module for Python 3.6.<br>
<br>
Paul<br>
<br>
PS Current launchers (py.exe, the entry point launchers from<br>
pip/setuptools, etc) tend to spawn the actual python program in a<br>
subprocess. I believe there are *technically* some differences in the<br>
runtime environment when you use an embedding approach like this, but<br>
I don't know what they are, and they probably won't affect 99.9% of<br>
users. Lack of support for binary extensions is likely to be way more<br>
significant.<br>
<div class="HOEnZb"><div class="h5">_______________________________________________<br>
Python-Dev mailing list<br>
<a href="mailto:Python-Dev@python.org">Python-Dev@python.org</a><br>
<a href="https://mail.python.org/mailman/listinfo/python-dev" target="_blank">https://mail.python.org/mailman/listinfo/python-dev</a><br>
Unsubscribe: <a href="https://mail.python.org/mailman/options/python-dev/rymg19%40gmail.com" target="_blank">https://mail.python.org/mailman/options/python-dev/rymg19%40gmail.com</a><br>
</div></div></blockquote></div><br><br clear="all"><div><br></div>-- <br><div class="gmail_signature"><div dir="ltr"><div><div dir="ltr"><div dir="ltr"><div dir="ltr">Ryan</div><div dir="ltr">[ERROR]: Your autotools build scripts are 200 lines longer than your program. Something’s wrong.<br></div><div dir="ltr"><div><a href="http://kirbyfan64.github.io/" target="_blank">http://kirbyfan64.github.io/</a><div style="display:inline-block;width:16px;height:16px"> </div></div></div></div></div></div></div></div>
</div>