Add setuptools integration.

[dave-shawley]

This PR adds a setuptools command for running safety check. I'm not sure if this is something that you are interested in or not, but it makes configuration via setup.cfg possible.

[codecov]

Codecov Report

Merging #218 into master will increase coverage by 3.54%.
The diff coverage is 100%.

@@            Coverage Diff             @@
##           master     #218      +/-   ##
==========================================
+ Coverage   74.28%   77.83%   +3.54%     
==========================================
  Files           7        8       +1     
  Lines         350      406      +56     
==========================================
+ Hits          260      316      +56     
  Misses         90       90

Impacted Files	Coverage Δ
safety/command.py	100% <100%> (ø)

---

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...abd3819. Read the comment docs.

[3clypse]

It's a great feature to add :)

[rafaelpivato]

This looks really good. There is one point I would like to discuss anyway.

My understanding is that the setup command, as another interface to Safety, should be adapt itself to such context. So, instead of allowing users to pass any argument as they would to to Safety CLI, just makes it sound like having two ways of doing the same thing. What I am trying to say is that users could then just call the CLI and that's it.

So, my proposal here is to change the arguments interface, and how the command gathers options from setup call itself, to run the check.

I will give you an example:

1. Remove all options except for those changing results format and the key: bare, json, full-report and key
2. Bring minimum set of options to setup call like: ignore, output, cache, db and files
3. Make sure we are running a check against install_requires dependencies by default.

In a way or another, this already looks great! Looking forward your changes.

[rafaelpivato]

Just curious, don't we need an = here?

[dave-shawley]

Yes ... yes you do 😞

[rafaelpivato]

Maybe we could explain briefly how the users should configure their setup.py file, including adding safety to setup_requires.

[rafaelpivato]

Shall we use safety.safety instead of safety.cli?

My understanding is that cli module serves as an interface for the console solely. Setup command would be another interface IMHO.

[dave-shawley]

My understanding is that the setup command, as another interface to Safety, should be adapt itself to such context. So, instead of allowing users to pass any argument as they would to to Safety CLI, just makes it sound like having two ways of doing the same thing. What I am trying to say is that users could then just call the CLI and that's it.

So, my proposal here is to change the arguments interface, and how the command gathers options from setup call itself, to run the check.

I will give you an example:

1. Remove all options except for those changing results format and the key: bare, json, full-report and key
2. Bring minimum set of options to setup call like: ignore, output, cache, db and files
3. Make sure we are running a check against install_requires dependencies by default.

In a way or another, this already looks great! Looking forward your changes.

Using install_requires is a perfect default... not sure why I didn't think of that. The main reason that I offered all of the options is to make them configurable via the setup.cfg. It does make sense to remove some of them.

1. Remove support for the proxy parameters
2. Remove support for the --stdin parameter
3. Initialize the list of packages with install_requires
4. Add packages explicitly specified in the files parameter to the list of packages

Does that sound good?

[rafaelpivato]

That would be great, @dave-shawley

Looking forward those changes!

[Lucas-C]

Hi!
This looks very useful :)
What's the status of this PR?