5 ms·

If you take this further, and can compile any of the "C" code (open source), then you can link that existing code as one single binary - e.g. "python" - basical

by malkia 8y ago

If you take this further, and can compile any of the "C" code (open source), then you can link that existing code as one single binary - e.g. "python" - basically python with all compiled code needed, thus: - You no longer need .dll, .so, etc. to go along, you can package the rest of the .py files into a .zip and slap it at the end of the now "fat" python binary, hence effectively having one executable - a bit of a "go" style releasing... - This can even have smaller sizes, but careful (with FFI) - because only the code that is exposed to be used from Python would get linked in the fat "python" binary.. that is - with "FFI" is more tricky, as you have to force symbol to be kept - You can obviously do that with other runtimes - java - e.g. your whole "java" can be down to one executable really But to get there, you need sane build system, in order to explain these dependencies outside of python/java/whatever... And obviously the source code (although precompiled static libs should work in this scheme too)... The goal again - just to have one thing, and most importantly no .so, .dll, .dylib lying around,

icebraining 8y ago
This is what tools like py2exe and PyInstaller do.
- paavoova 8y ago
  You can do this with plain zip files as Python can unpack and execute in-memory. But you have to extract non-Python code such as C libraries at runtime somewhere so the OS can link them. I would be interested to know how the packagers you mentioned get around this, or if they too use temporary files and unpack.
  - dead_mall 8y ago
    This is exactly how I package my python scripts. The answer to your question: Memfd https://magisterquis.github.io/2018/03/31/in-memory-only-elf-execution.html https://magisterquis.github.io/2018/03/31/in-memory-only-elf... And zipimport pip package
    - malkia 8y ago
      Right, there are OS-specific approaches on all systems, but if you are able to compile Python itself along all open source C/C++ libs that your .py-thon file might use, you end up with exactly one executable (you can possibly even go further packaging the .py files in some compressed (bytecode compiled) inside the same binary) - e.g. all you need is there, and the approach would fare better across more systems (e.g. does not rely on advanced techniques, no need to unpack the .DLL in temp folder, etc.). Also better for post-mortem debugging - your .PDB, and your .DWP (or whatever symbol files) are.. well just one single file, rather than several. Same thing for java, dart, etc. This makes it much easier to deploy, use, download, as it's basically "zero"-config install, no need for scripts to tweak your PATH, etc. (but it has limitations clearly, if you use proprietary code, or you can't compile given open source library bundled with you - e.g. LGPL code, that you have to dynamically link, then again if you are project is open source this is no longer that much of a limit (but would not know that for sure))

by malkia 8y ago

icebraining 8y ago

This is what tools like py2exe and PyInstaller do.

paavoova 8y ago
You can do this with plain zip files as Python can unpack and execute in-memory. But you have to extract non-Python code such as C libraries at runtime somewhere so the OS can link them. I would be interested to know how the packagers you mentioned get around this, or if they too use temporary files and unpack.
- dead_mall 8y ago
  This is exactly how I package my python scripts. The answer to your question: Memfd https://magisterquis.github.io/2018/03/31/in-memory-only-elf-execution.html https://magisterquis.github.io/2018/03/31/in-memory-only-elf... And zipimport pip package
  - malkia 8y ago
    Right, there are OS-specific approaches on all systems, but if you are able to compile Python itself along all open source C/C++ libs that your .py-thon file might use, you end up with exactly one executable (you can possibly even go further packaging the .py files in some compressed (bytecode compiled) inside the same binary) - e.g. all you need is there, and the approach would fare better across more systems (e.g. does not rely on advanced techniques, no need to unpack the .DLL in temp folder, etc.). Also better for post-mortem debugging - your .PDB, and your .DWP (or whatever symbol files) are.. well just one single file, rather than several. Same thing for java, dart, etc. This makes it much easier to deploy, use, download, as it's basically "zero"-config install, no need for scripts to tweak your PATH, etc. (but it has limitations clearly, if you use proprietary code, or you can't compile given open source library bundled with you - e.g. LGPL code, that you have to dynamically link, then again if you are project is open source this is no longer that much of a limit (but would not know that for sure))