google
Allow lockfile to be read from STDIN
It would be helpful to read the lockfile from STDIN. For the Python use case, that would enable something like this:
python -m pip freeze -r requirements.txt | osv-scanner -L -
By allowing pip to identify the transitive dependencies, I get a more complete scan.
I would expect that this enhancement would be stuck behind #94, as STDIN removes the naming hints for the lockfile type.
fwiw supporting this "natively" (i.e. without writing a temp file to disk) would require a refactor of the whole lockfile package because it accepts a path to a file, and there's a couple of different ways the reading is done so it's not just a case of changing them to accept a stream/io type object.
Personally I think using a temp file is the way to go (at least for now) because while arguably that defeats the point of using a pipe, the scanner can't actually take advantage of the file contents being streamed anyway in most cases (and I doubt it'd ever be able to) - you should be able to archive that in userland right now by doing:
python -m pip freeze -r requirements.txt > /tmp/requirements.txt; osv-scanner -L /tmp/requirements.txt
(of course #94 will make that easier)
Having said that, I think it's reasonable for the scanner to support sorting out the temp file when you give it - as an input.
Somewhat related, I'd love to see external lockfile parsing functions take a (path name and) io.Reader. I would like to use this package's parsing capabilities outside of usage with the osv-scanner CLI tool directly, and don't always have a path to a file on disk.
I could use a similar temporary file path solution, but that doesn't seem ideal.
@picatz could you create a new issue for that, as it can be actioned separately - the reason why I originally wrote the parsers to take a string is that they use one of ~3 methods for reading the file, not all of which I think just take an io.Reader as a straight drop-in (I'm sure it's probably possible though), and generally at the time the parsers I was writing were for tools that should always have a lockfile on disk (I always knew it'd be possible to have this use-case especially with automated tooling, but it was a "solve later" problem).
My ideal state would be having the parsers in their current form/func name take io.Reader and then have a paired parse<lockfile>FromFile function, but that'd be a breaking change - instead I think what @cmaritan has done in #164 with ParseApkInstalledFromReader is the way to go (which could be done right now for some of the parsers)