Dependency Installation for Software Projects

Here is a characterization of the various common ways there are to install the dependencies needed for a particular piece of software. For software development purposes. I'm taking a stand here and saying some ways are better than others, and I'm taking this stand based on years of experience seeing what seems to work better than others, and what causes more problems and headaches or consumes more time than others. Approximately speaking, the top-most methods are the best, descending down to the worst. One is ideal. But two also rocks. Three is doable but doesn't use humans time well, will NOT work on a headless device like a true server or embedded unit, and is prone to mistakes. The rest? All downhill from there.

  1. all files needed are already in the repo tree at code checkout time, linked to automatically at build-time and runtime as needed; no install tasks needed, they're versioned along with your application source and go everywhere it goes
  2. CLI script that automatically fetches, configures and installs everything needed, possibly outside the checkout tree; caching intelligently
  3. single GUI wizard process, with clicky-clicky
  4. multiple separate GUI wizard processes, with clicky-clicky-clicky-clicky-clicky
  5. above plus having to manually tweak and edit random various config settings and params in GUI Control Panel and/or Terminal, clicky-clicky-clicky-clicky-tap-tap-tap-tap-toggle-tap-toggle-slide-toggle-clicky-clicky-tap-tap-clicky-tap-tap-#*%&#*&%*##
  6. above and/or a binary "Registry" has been magically modified somewhere by the GUI install process, in mysterious ways with mysterious side effects, in seemingly duplicate locations, with hexadecimal jibber-jabber and/or XML, and woe unto him who does anything with just the files themselves or in Terminal without letting the Registry know --- *shoots self in head now*
AKA
  1. the Java way (a lib subdir of jars)
  2. the Unix way (ideally a single shell script that avoids PMS (package management system); less ideal: intelligent CLI invokable PMS)
  3. the Mac/Windows way
  4. the Mac/Windows way
  5. often the Windows way, never seen it on Mac but can't rule it out ... smart BAT scripting can avoid it
  6. the Windows way, of course ... and not sure it's avoidable for certain apps
NOTE: I am speaking in broadstrokes, with a bias to wearing the programmer's hat, to staying in a terminal as much as possible, and with a preference for rapid development cycles. There are also use cases where a unified system-wide package management system is also ideal (where apps have external local dependenices on common libs, like for encryption) and if I were a sysadmin/DevOps I might bias first to #2 and #3 rather than #1. Bottled (batteries-included) app deployments are both more stable and less stable, dependending on your perspective and the time scale under consideration. Though I think the net trend and what's considered "best practice" has been increasingly moving away from having apps with external local dependencies and towards a bottled/static blessed binary build image (eg. see Go by Google, designed ostensibly to make their SREs more happy). Arguably the Go Way is a variant on #1 that is distinct enough to warrant me breaking it out separately, but I'd have an ever harder time of making a broadstrokes generalization as to which of those two methods is superior by default. Though I think the "Java tree of jars" way is better in Dev and at smaller scales, whereas the "Golang unified binary" way may be better in Prod and at extreme scale with an extreme 9's QoS goal.

TODO: revise to address package management systems better, more nuance, be more clear


UP