[Python-Dev] Single-file Python executables (was: Computed Goto dispatch for Python 2)

[Paul Moore]

On 28 May 2015 at 22:09, Glenn Linderman <v+python at g.nevcal.com> wrote:
> This would be something I could use and benefit from immediately upon it
> being available, so I laud your idea, and hope you have a successful
> implementation, and look forward to using it.  It would largely replace the
> need for the py.exe launcher for some classes of applications.

The following proof-of-concept works as is (based on my pretty minimal
testing), and only uses the limited API, so it should work with any
version of Python 3 (I've not tested it with Python 2, but I think the
only "new" API is PySys_SetArgvEx, which could be replaced with
PySys_SetArgv at a pinch). Excuse the dreadful coding style and lack
of error handling, I hacked it up in about an hour :-)

(Actually, I just tried building on Python 2 - guess what - Unicode
:-) SetProgramName and SetArgvEx won't take Unicode values. The easy
fix is just not to use Unicode, the hard one is to do the encoding
dance, but I'm not going to bother...).

#define UNICODE
#define _UNICODE
#include <Python.h>
#include <windows.h>

int
main()
{
    TCHAR program[MAX_PATH];
    LPWSTR *argv;
    int argc;
    PyObject *runpy;
    PyObject *ret;

    argv = CommandLineToArgvW(GetCommandLineW(), &argc);
    GetModuleFileName(NULL, program, MAX_PATH);
    Py_SetProgramName(program);  /* optional but recommended */
    Py_Initialize();
    PySys_SetArgvEx(argc, argv, 0);
    runpy = PyImport_ImportModule("runpy");
    if (!runpy) PyErr_Print();
    ret = PyObject_CallMethod(runpy, "run_path", "u", program);
    if (!ret) PyErr_Print();
    Py_Finalize();
    return 0;
}

One mildly annoying thing is that python3.dll is only installed in
<python install dir>\DLLs, which typically isn't on PATH. So actually
using the limited API from your own application fails by default.
Fixing that's mostly a user admin issue, though (and you can just link
to the full API and avoid the whole problem).

> Of course, per other disccusions, this doesn't solve the problem for:
>
> A) machine without Python installed
> B) programs that need binary extensions
>
> Other discussions have suggested:
>
> 3) The stub could offer to download and install Python
>
> A corollary:
>
> 4) The stub could offer to download and install the needed binary extensions
> as well as Python. This would require the installation uniformity of
> something like pip, so perhaps would be restricted to extensions available
> via pip.  And it would be much enhanced by some technique where the zipapp
> would contain metadata readable by the stub, that would declare the list of
> binary extensions required.  Or, of course, it could even declare non-binary
> extension that are not packaged with the zipapp, if the process is smooth,
> the modules available via pip, etc., as a tradeoff.

I'm pretty strongly against downloading interpreters or extensions.
Apart from the pretty huge added complexity, as a user I'm not sure
I'd trust a supposedly simple application I'd received if it started
asking to download stuff unexpectedly...

Paul