Closed lread closed 3 months ago
I think I would prefer options 3 + 4 combined:
--run-without-nvd-api-key
(no short version) and print out a big warning about slow downloads (and make that clear in the docs)--run-without-nvd-api-key
is not supplied and no nvd.api.key
property is provided, refuse to run and explain whySounds good to me!
Note also: Related to #68, there is some warn
level logging from dependency-check (that we are currently suppressing) around the absence of api key. But hitting folks over the head with warnings and making it hard for them to do the wrong thing makes sense for this use case.
@seancorfield clj-watson is using cli-matic, which is ok, but I'm having trouble expressing what I'd like to here. I'm going to switch over to babashka/cli which is nice to work with and very actively maintained.
OK, just bear in mind the -T
argument handling is all done through DEFAULTS
and ABBREVIATIONS
-- I don't know how tied to cli-matic
that format is...
Thanks Sean, I'll create a separate to issue explore and isolate the work.
Currently
When no nvd api key is specified, we quietly ignore that fact, and, attempt to interact with the nvd api.
But
There are real benefits to specifying an api key:
Options
Option 1 - Do nothing
Users should read the docs. Let 'em suffer it they don't.
Option 2 - Add a very prominent warning if no nvd api key was specified
I think ANSI colors to make the warning really pop would make sense here.
Option 3 - Fail fast if not nvd api key specified
Force the issue. Don't allow api-key-less usage with clj-watson.
Option 4 - Allow api-key-less usage only via special cmd line arg
Maybe
--run-without-nvd-api-key
. This forces the user to very deliberately run without an nvd api key.Proposal
I like option 3. If we learn that folks feel this was a bad choice, we can always adapt with option 4.
Next Steps
I am happy to discuss this further, and if we agree on an approach, I can work on a PR.