How to deal with interpreter dependencies

Question

Consumer software often has interpreter dependencies. How should a situation where the required interpreter is not by default installed on the targeted system be handled for consumer software, soft for non-technical people?

Bellow, I give an example with Node.js and macOS, but my question applies equally to other platforms.

---

Let's say I release some consumer software for macOS written to be run with Node.js (via a shebang). macOS doesn't have Node.js installed by default, so I guess there are two-ish major options here:

• Pack Node.js into my software
• Mention that Node.js is required to run the software on the download site
• (Include a piece of software that can be run by default, that is run before the main program. This piece of software checks if Node.js is installed. If not, it should ask the user whether he would like to install the required dependency and help him to do so.) ~ Would work, but this doesn't seem to be a common thing.

I've seen both options used extensively (although not per se with the Node.js and macOS example combo). Both have their pros and cons.

Having the user install Node.js on their system is probably quite a bit of a hassle for non-technical people.

Packing the entire Node.js runtime with an application is also not that ideal, especially for software where the interpreter takes up more space than the actual application code. If all apps on the users computer would do this, the majority of the disk would be filled up by packed Node.js-executables, though only one global one would really be required.

Answer 1

This actually depends a lot on package dependency handling and user expectations.

• Linux distributions typically have packaging systems that allow dependencies to be expressed such that interpreters or other required software will automatically be installed, and most users will expect software installs to work that way.
• Windows application installers often install all required dependencies with the application, which can lead to duplicate versions of libraries. For some common libraries such as the redistributable dlls or the DotNet CLR they may check whether a usable version is installed already and offer to install one if not.
• For MacOS, I don't really know as I'm not using it. Colleagues who tried to install Python software told horror stories about incompatible installations, Anaconda, etc. I guess this problem isn't really solved satisfactorily, application authors are expected to bundle everything into a single app.

Answer 2

In practice, requiring library/interpreter/resource X almost always means requiring a specific version of X. But only one version of X can be installed as the global default, and users hate having to care about configuring/installing/maintaining their global default; they only want stuff done.

Therefore, the balance in the trade-off between "depending" and "bundling" skews heavily toward "bundling". Just bundle the damn thing and easily double your potential user base.

Sure, for an engineer it's annoying and redundant to have multiple node.js on a machine when technically, fewer would do. But guess what? Your users are overwhelmingly not engineers, or technical. The question you must ask is not "Is the dependency larger than my program?", but "Is the dependency so large that there is a considerable risk that many users will not be able to fit it on their drives?". Given current trends in hardware, the answer to that is almost always "No."

Answer 3

As the answer by Hans-Martin Mosner explain it depends on the target system and the user expectations. But there is something to add. If you choose to bundle all the dependencies in one package you should know very well what you are doing and you should be able to create a self contained environment. I don't know about Apple, but often in Windows and sometimes also in Linux it happens that a poorly prepared installer changes the version of some existing library and breaks the dependencies of other applications.

In your case:

I would exclude the first option because if you don't care for the environment variables some libraries of unknown version might be loaded from the default executable directories.

For the third option you could extract everything in one directory and provide a shell script that adds the directory to PATH, LD_LIBRARY_PATH or other environment variables and then starts a console.

If a self contained environment won't work, or you are unsure, it is better to stay on the safe side and just mention the dependency as stated in the second option.