Add an audit method to IAppliance

[slifty]

Task

Description

Appliances will regularly have external dependencies outside of npm (e.g. imagemagick, ffmpeg, ccextractor, tesseract, etc). Given this, we would like appliances to have a health check that makes it possible to programmatically confirm that the dependency needs are met (and ideally share some clues as to what action must be taken to meet them).

Lets add an abstract audit method to IAppliance.

Relevant Resources / Research

None.

Related Issues

• How should appliances be installed? countertop#65

[slifty]

Some implementation questions:

• Should doctor error when something is wrong?
• Should it simply log when something is wrong and return false?

Erroring would halt doctor which means if more than one thing is wrong only the first issue would be exposed in a given run (this is what eslint does and it's kind of obnoxious). However, it would be more explicit. There might be benefit to a custom Error in this case in order to provide more information around the error (e.g. resolution suggestion).

Logging and returning false might be appropriate as well, since a doctor method is actually functioning properly if it detects error (whereas throwing an error might indicate doctor itself failed somehow).

[reefdog]

Without exploring what others do yet: the result of doctor should be a clean bill of health or a dirty bill of health with specifics. (When I run brew doctor, I assume it will tell me all the things I need to fix. Actually, come to think of it, brew doctor tries to fix them, so that's not quite analogous. Oh man should this be triage instead of doctor?? jkjk I like doctor) So yes, erroring out upon first missing dependency would be obnoxious, IMO.

[slifty]

I do wonder if doctor does imply fixing and if we should be looking at another term.

Here's the brew doctor documentation:

$ brew help doctor
brew doctor:
    Check your system for potential problems. Doctor exits with a non-zero status
    if any potential problems are found. Please note that these warnings are just
    used to help the Homebrew maintainers with debugging if you file an issue. If
    everything you use Homebrew for is working fine: please dont worry or file
    an issue; just ignore this.

Meanwhile here is documentation for brew missing (I don't think missing is right for us, but just for context)

$ brew help missing
brew missing [--hide=hidden] [formulae]:
    Check the given formulae for missing dependencies. If no formulae are
    given, check all installed brews.

    If --hide=hidden is passed, act as if none of hidden are installed.
    hidden should be a comma-separated list of formulae.

    missing exits with a non-zero status if any formulae are missing dependencies.

[slifty]

Some quick names for consideration: health, test, verify, doctor, check, healthCheck, depdencyCheck

A few terms and notes that came out of Slack discussion:

preheat qualityInspection validate preflight prelaunch
conform guarantee assure inspect diagnose

maintenance maintenanceCheck

mechanic might be more appropriate than doctor since we're dealing with Appliances...

Note that Ruby has gem check which is something of a file level check it seems.

[slifty]

Names aside; how should appliances access the logger. If doctor (or mechanic, which I'm leaning towards...) is expected to output instructions instead of throw errors, then we may need appliances to be passed a logger, or maybe we just recommend the use of console.error.

[reefdog]

After lots of thought I think audit is perfect.

[slifty]

I think @louh nailed it!

[reefdog]

What do you mean @louh, I clearly came up with it, here, in GitHub, just now, me.

[reefdog]

(For the sake of future digital archeologists: yes, the rest of us were babbling about hoopsuckers and hudswingers when @louh came in with a "fellas, fellas, I got something!")