Skip to content

docs: Add docstrings to available_fix/debian_cve_tracker.py #4540

Closed
@terriko

Description

@terriko

We haven't been entirely consistent about adding python docstrings to every function, and I figured I'd file some easy to fix issues for hacktoberfest participants who are maybe working on getting their commits in this week.

What is a docstring?

Here's a tutorial on
docstrings
in case
you're not sure what they are. Basically I want someone to write a short
sentence explaining what a function does and have it put at the top of the
function in the way that python expects docstrings to look. (You can also do
classes and methods.) Among other things, docstrings can be used by integrated
development environments (IDEs) to give contributors a quick overview of the
function without having to read the code.

This issue

This issue is for updating the file listed in the title of the issue: available_fix/debian_cve_tracker.py

$ interrogate -vv -i -I -M -C -n -p -f 60.0 available_fix/debian_cve_tracker.py
=============== Coverage for /home/terri/Code/cve-bin-tool/cve_bin_tool/available_fix/ ===============
----------------------------------------- Detailed Coverage ------------------------------------------
| Name                                                              |                         Status |
|-------------------------------------------------------------------|--------------------------------|
| debian_cve_tracker.py                                             |                                |
|   DebianCVETracker (L35)                                          |                         MISSED |
|     DebianCVETracker.cve_info (L41)                               |                        COVERED |
|     DebianCVETracker.get_data (L74)                               |                         MISSED |
|     DebianCVETracker.compute_distro (L79)                         |                         MISSED |
|   check_json (L86)                                                |                        COVERED |
|   update_json (L96)                                               |                        COVERED |
|-------------------------------------------------------------------|--------------------------------|

---------------------------------------------- Summary -----------------------------------------------
| Name                           |          Total |          Miss |          Cover |          Cover% |
|--------------------------------|----------------|---------------|----------------|-----------------|
| debian_cve_tracker.py          |              6 |             3 |              3 |             50% |
|--------------------------------|----------------|---------------|----------------|-----------------|
| TOTAL                          |              6 |             3 |              3 |           50.0% |
--------------------------- RESULT: FAILED (minimum: 60.0%, actual: 50.0%) ---------------------------

You can run that locally to see if you're done, but we also recommend using
pre-commit to run pre-checks for you before submitting a pull request.
Instructions here:

https://cve-bin-tool.readthedocs.io/en/latest/CONTRIBUTING.html#using-pre-commit-to-run-linters-automatically

Or in short, go to the main cve-bin-tool directory and run the following:

pip install pre-commit
pre-commit install --hook-type pre-commit --hook-type commit-msg

Short tips for new contributors:

  • cve-bin-tool's contributor docs
  • If you've contributed to open source but not this project, you might just want our checklist for a great pull request
  • cve-bin-tool uses https://www.conventionalcommits.org/ style for commit messages, and we have a test that checks the title of your pull request (PR). A good potential title for this one is in the title of this issue.
  • You can make an issue auto close by including a comment "fixes #ISSUENUMBER" in your PR comments where ISSUENUMBER is the actual number of the issue. This "links" the issue to the pull request.

Claiming issues:

  • You do not need to have an issue assigned to you before you work on it. To "claim" an issue either make a linked pull request or comment on the issue saying you'll be working on it.
  • If someone else has already commented or opened a pull request, assume it is claimed and find another issue to work on.
  • If it's been more than 1 week without progress, you can ask in a comment if the claimant is still working on it before claiming it yourself (give them at least 3 days to respond before assuming they have moved on).

Metadata

Metadata

Assignees

No one assigned

    Labels

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions