var-naming: `api` is not a meaningless package name

[alexandear]

disagree:

golangci/golangci-lint#6232

api.GetObject() seems to be a good name - worked for us for years, as well as numerous other Go APIs that AIStore provides...

Originally posted by @alex-aizman in #1588

[alexandear]

Related issue: "var-naming: add more bad package names" #1460

[ccoVeille]

We knew it could lead to report things in old projects. I would say here it's about a pseudo false positive.

Having an API is OK on some projects, but not on others.

If I had such reporting in a project, I would use a nolint and move on.

But we could consider removing API from "bad package" names

[alexandear]

@alex-aizman the package name api is considered "bad" because of this Go blog post:

Don’t use a single package for all your APIs. Many well-intentioned programmers put all the interfaces exposed by their program into a single package named api, types, or interfaces, thinking it makes it easier to find the entry points to their code base. This is a mistake. Such packages suffer from the same problems as those named util or common, growing without bound, providing no guidance to users, accumulating dependencies, and colliding with other imports. Break them up, perhaps using directories to separate public packages from implementation.

And yeah, Revive’s suggestion is not a dogma. If api works for you, you can disable it in your .golangci.yml configuration file:

linters:
  exclusions:
    rules:
      - text: "avoid meaningless package names"
        source: "package api"
        linters:
          - revive

On the other hand, we could remove api from the bad package names list.

[bconway]

I would argue that api may be a bad package name in the context of a general application programming interface, but it is not when it is the top-level package name of an API service/binary. I have the latter currently popping up warnings in a number of projects with the latest release.

[chavacava]

On the other hand, we could remove api from the bad package names list.

Since the rule already accepts extraBadPackageNames (among other configuration keys) we could provide its complement: acceptPackageNames (or something like that)

[chavacava]

Since the rule already accepts extraBadPackageNames (among other configuration keys) we could provide its complement: acceptPackageNames (or something like that)

Drafted at https://github.com/mgechev/revive/tree/feature/var-naming-acceptedPackageNames