fpgmaas/deptry

Replace the word 'obsolete' with 'unused'

fpgmaas opened this issue · 2 comments

I think the term 'obsolete' dependency might be slightly vague to some users, and the term 'unused' dependency might be more clear. In fact, in most of the situations where people find deptry, they are actually looking for a way to get rid of 'unused dependencies', rather than 'obsolete dependencies'. See e.g. here and here. When searching for "unused dependencies" on Google, I find about seven times as many hits as when I search for "obsolete dependencies".

It seems "unused dependencies" is a more commonly used term, so I think it could make sense for us to replace the occurences of the word 'obsolete' to 'unused' within deptry. This could help users better understand the tool's purpose and make it easier for people to find.

The error message we currently display also does not show the word 'obsolete' but does say 'not used': https://github.com/fpgmaas/deptry/blob/main/deptry/violations/obsolete.py#L15

The drawback is that we would also have to rename some of the CLI's flags, so this would be a breaking change. If we decide to go through with this, we could:

  • (a) Just replace --ignore-obsolete with --ignore-unused and replace --skip-obsolete with --skip-unused.
  • (b) Replace them and throw an error when someone uses the old flags, letting the user know they are deprecated, and instruct the user to use the new flags.
  • (c) Add the options instead of replacing, combine the user's input for the old and the new options, and raise a warning that the old flags will be deprecated in the future.

I think option (c) might be the cleanest? The linked MR currently implements this option.

Curious for your thoughts.

It's a sensible change, as "unused" is more factual than "obsolete", so I am definitely onboard with the change.

Regarding the addition of the new CLI flags, I would be more in-phase with option c. We are not 1.0 yet but it's still a good idea to think about being retro-compatible, and not introducing unnecessary breaking changes if this is not too costly to maintain previous behaviours.

Although instead of combining the outputs, maybe we could simply error out instead when both the old and new options are used?

From a user perspective, users that fall into the case of using both options would probably be users that have read the changelog and decided to use the new option, so it might be better to make sure they only use the new option.

I think that's a good idea, I updated the linked PR to reflect the changes.