Loading code without the disk: what each OS lets you get away with
memfd, PE loaders, unlink-after-dlopen. Three operating systems, three different definitions of 'in memory'.
A developer tool for shipping smaller PyInstaller and PyArmor builds to clients by loading packages from memory at runtime.
paker packs a Python package tree, including native extensions, into an encrypted bundle and imports it from memory. A PyInstaller or PyArmor build no longer has to carry every dependency inside the binary: the dependencies arrive at runtime, and the binary you ship to a client gets smaller.
bundle = paker.dumps("myapp", key=key, include_deps=True) # on your machine
with paker.loads(bundle, key=key): # on the client
import myapp
myapp.run()
.py, .pyc and native extensions (.so, .pyd, .dll), loaded without writing them to disk where the
operating system allows it. Each platform needs a different trick; this post covers all three.importlib.resources.The encryption started as an attempt at code obfuscation. I wouldn’t lean on it today: coding agents are good at reverse engineering, and a determined reader with one will get through. The smaller builds and the runtime loading don’t depend on it.
paker is meant for professional use, for packaging your own software and shipping it to your own clients.
memfd, PE loaders, unlink-after-dlopen. Three operating systems, three different definitions of 'in memory'.
Encrypt a Python package tree, ship it over the network, load it from memory. What works, what doesn't.