Create blog post explaining difference in approach with PyOxidizer

[ronaldtse]

From @maxirmx :

They use Rust to package and rub the solution and C-Python module to implement custom importing functionality.

I would point to two major differernces:

1. In tebako we intercept filesysem OS calls while PyOxidizer implements custom 'import' ( ~ 'require' for Ruby case)

2. we just run patched ruby and they have some wrapper around python.exe No sure why, possibly it is a consequence of the first difference

I think the python packaging procedure that they describe is overcomplicated comparing to what we have for Ruby. But it is possible that Python cannot be packaged simplier.

Also PyOxidizer is much better exposed to the community, they have documentation, contributors and other thing that we miss.

In tebako "linking" is much more complicated then "virtualization".
I mean that intercepting and re-implementing file system access is straightforward.

Considering the nature of dwarfs creation of an executable without external dependencies is magic.

Tebako patches Ruby source files.

It injects C #define statements that reroute a subset filesystem access functions to libdwarfs implementations.

libdwarfs wisely routes call either to dwarfs methods to access packaged files from in-memory filesystem or to libc methods if host filesystem is needs to be accessed.

Some gems with native extensions use direct calls to libc to access packaged files. Such gems/extensions and files require special handling. In the current version we unpack files to temporary folder and redefine certain gem methods on case by case basis to reroute extension calls to tempory folder.