On 28 May 2015 at 22:09, Glenn Linderman <v+python@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