Improve "Granular" Setting / Possibility to pin a Deepsource version

Hi.

IISC the current status of DS is that once new checks are added, or existing ones are extended/improved, this behavior is rolled out directly to all new checks. I had a few PRs, where this lead to the DS check failing b/c it reported issues that

  • weren’t a direct cause of the changed lines
  • hadn’t been reported before

Note that the “Granular” setting is supposed to prevent this, but apparently this doesn’t always work. Here is an example, where DS reports issues for the ClassName.check_update method, while the PR only changed the docstring of the class. A similar case in the same PR is here.

It would be nice, if the “granular” setting would be improved.

Additionally, I would find it desirable to be able to pin a specific DS version (eg via .deepsource.toml#version), which prevents new changes in the DS system to apply directly. This would

  1. help eliminate many of the above issues
  2. allow devs to apply new issue-fixes concisely to the whole code base by bumping the version & addressing revealed changes - instead of discovering them bit by bit in each PR.

Looking forward to your feedback :slight_smile:

1 Like

Thanks for your feedback, @Bibo-Joshi!

When we add new checks to an analyzer or improve existing checks to fix false positives, they’re immediately rolled out to all new analysis runs. I understand how this can be undesirable if you have long-standing PRs and new issues popping up after a new commit is made. We can probably refine the behavior to avoid reporting new issues if they’re not strictly in the changeset.

The config file version field isn’t intended for this, but I understand how a “versioning” mechanism could help. In principle, we’d like to solve this implicitly without you having to change any versions.

I’ve noted your feedback internally, and I’ll get back with more details in this thread once we have triaged this and have an action item. :raised_hands:t3:

1 Like

Hi. Over one year later, we face the same issue once again in this pr. In this case, I can’t even find any DeepSource Changelogs that indicate when py-r1000 was added …

Yes, we’ve added PY-R1000 as part of our upcoming release related to supporting complexity metrics in DeepSource. You should see the updates in the next changelog. Apart, we have a solution for this in our backlog. I’ll report back on this thread as soon as we have updates.

Thanks again for your feedback!