Allow lockfile to be read from STDIN

[corey-cole]

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.

[G-Rath]

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.

[picatz]

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.

[G-Rath]

@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)

[picatz]

Thank you for the quick response @G-Rath, happy to make an issue!