add support for Pipfile.lock

[nim65s]

Hi,

This PR adds support for Pipfile.lock (https://github.com/pypa/pipfile), with a new -p option for the CLI, a really simple read_pipfile util inspired from the existing read_requirements, and a unit test.

Another option to add this suppport (and support other formats), would be to refactor read_requirements to let dparse get the requirements from multiple formats, maybe with a CLI switch with dparse.filetypes as choices.

[codecov]

Codecov Report

Merging #216 into master will decrease coverage by 0.12%.
The diff coverage is 62.5%.

@@            Coverage Diff             @@
##           master     #216      +/-   ##
==========================================
- Coverage   74.28%   74.15%   -0.13%     
==========================================
  Files           7        7              
  Lines         350      356       +6     
==========================================
+ Hits          260      264       +4     
- Misses         90       92       +2

Impacted Files	Coverage Δ
safety/util.py	62.9% <100%> (+1.88%)	⬆️
safety/cli.py	54.87% <40%> (-0.82%)	⬇️

---

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 3b81f90...dc696c4. Read the comment docs.

[GhostofGoes]

Why have a separate argument for Pipfile instead of using -f and checking the filename?

[nim65s]

Because we don't have access to the filename when using stdin.

But what we could do would be to check if the file contains valid JSON data, and in this case assume it is a Pipfile.lock. eg: nim65s@575636a

I'll let the maintainers of this project choose :)

[rafaelpivato]

The code looks really good. What I am trying to judge is whether it would make sense to add another file read function here. You pointed it very well at the beginning of your PR that we might instead need a refactor and properly use dparse library to read requirements from virtually any file.

I see why you added another option, but as @GhostofGoes noticed, we should just use -f instead. Detecting the file type, or being able to parse different file types, is for sure a dparse responsibility. What I would not like to do is to add one another option for each file type. At most, if we see dparse will not be able to detect the file type, we should use one option to point out different possible file types.

[alvarolmedo]

+1