Vendoring a native tool while retaining maximum portability

Question

The Twelve-Factor App manifesto says that it is for web applications that "... Have a clean contract with the underlying operating system, offering maximum portability between execution environments" [emphasis added by me]

But then it says:

Twelve-factor apps also do not rely on the implicit existence of any system tools. Examples include shelling out to ImageMagick or curl. While these tools may exist on many or even most systems, there is no guarantee that they will exist on all systems where the app may run in the future, or whether the version found on a future system will be compatible with the app. If the app needs to shell out to a system tool, that tool should be vendored into the app.

and they have earlier defined "vendored into the app" as:

scoped into the directory containing the app (known as “vendoring” or “bundling”).

How should this be done, when (on Linux at least) native 64-bit executables do not run in 32-bit environments, for example - let alone on other operating systems? Or is there a better way of handling this portability issue?

Answer 1

In my opinion, it shouldn't be done at all. This is because:

• If the native executables are dynamically linked, there is a chance that they will fail to run merely on future OS releases, let alone future or past processor architectures.
• As far as I understand it, it is not possible to completely future-proof a native executable by statically-linking it. You can still have issues. Solaris doesn't even support static linking of system libraries!
• Library dependencies are not the only kind of dependencies that native tools can have. There can be other issues as well.
• Old ImageMagicks - or even curls - may have security bugs which could allow your application to be compromised. (This is a bit of a contentious point - its validity depends on who you trust more to watch for / apply security updates - the people who maintain and upgrade the servers, or the developers? Of course they might be the same people - for now. But my working assumption here is that the servers would have updates applied eventually, which would in turn protect your app from security holes in system executables that have been fixed in the updates.)

My view: If your dependency management system of choice simply point-blank cannot handle native executables, stick a note in the README and be done with it. If you don't have a README, create one. And (for in-house web apps) add the native tools you need to your standard server image or script that you use when setting up a server, and make sure you keep an additional note of why they are there.

Answer 2

It just means you should have a declarative dependency and a clean contract between your vendored resources.

If your app relies on a specific version of software, you have to make a clean contract with it so you can mock/stub functionality for development. Additionally, making dependency management part of your app is not impossible even in Windows (though you may want it to happen in your installer rather than the app itself).

If your product relies so heavily on other software that it cannot possibly function without it even in a test environment, then it has to be bundled, and you will have to work out the EULA or, really, you don't have a product.