Edit (per #32780 (comment)): I should have used go mod edit -exclude instead of the /dev/null replacement.

On one project I worked on, we deprecated a repository in favor of another. While refactoring, it was easy to accidentally reintroduce a dependency on the deprecated project, so I added a replace github.com/myorg/deprecated-project => /dev/null to go.mod.

But that is a total hack, and it gives you a not-very-informative message when you mistakenly import that package:

go: finding github.com/myorg/deprecated-project latest
foo.go:43:2: unknown import path "github.com/myorg/deprecated-project": cannot find module providing package github.com/myorg/deprecated-project

First-class support for blacklisting specific packages/modules is something I would have used in the past, had it been available.

@smoyer64 what are you using for an editor or IDE, and are you using goimports or gopls, or maybe something else?

Are you looking for functionality similar to .goimportsignore?

From https://godoc.org/golang.org/x/tools/cmd/goimports:

To exclude directories in your $GOPATH from being scanned for Go files, goimports respects a configuration file at $GOPATH/src/.goimportsignore which may contain blank lines, comment lines (beginning with '#'), or lines naming a directory relative to the configuration file to ignore when scanning. No globbing or regex patterns are allowed. Use the "-v" verbose flag to verify it's working and see what goimports is doing.

CC @stamblerre @heschik

@thepudds We're using a variety of editors but the most prevalent is VSCode with gopls under the hood followed closely by vim with vim-go. In both cases we could use .goimportsignore but that will "ban" a package globally. I'd like to be able to use go.mod to manage all my dependency versions (or lack thereof) on a project by project basis. We have used the replace trick above but we'd like to globally use a Git precommit hook that globally rejects go.mod files that contain replace constructs.

Regarding the specific proposal: go.mod deals with modules, not packages, so it would be pretty strange IMO to put ban log in there.

Regarding goimports: it already prefers imports that are present in the same package. So if you have a package with a file that has import log "github.com/sirupsen/logrus", then make a new file and use log, it should copy over that import. Theoretically it could consider the whole module for that sort of thing.

Ultimately this sounds like an editor feature to me. As a point of reference, Eclipse has the concepts of "favorite imports" and "type filters", which in combination sound very close to what you're asking for here.

It does seem a bit strange to ban the log package in go.mod as it's "well known". But go.mod definitely includes URLs for code that has not yet been converted into modules, so the case can be made that it handles packages now.

Following the thoughts related to .goimportsignore above, maybe the better answer would be to make goimports module aware. If you're in a module, why couldn't it use that file local to the module instead of the one in your $GOPATH?

go.mod has the path of repositories that have been implicitly converted to a module, like github.com/sirupsen/logrus. It never has package names like github.com/sirupsen/logrus/hooks/syslog.

I don't understand the focus on not adding the thing you don't want. Wouldn't it be better for goimports or the editor to add the thing you do want, i.e. import log "github.com/sirupsen/logrus"?

Well ... if everything always worked in the way you imagine, you wouldn't need to to focus on the negatives (which would be more pleasant as is general in life). I've been using Maven for Java dependency management for many years and there are still occasions where you need to force dependency versions (as you can in Go modules) or exclude dependencies as I'm suggesting here. If a very mature and IMHO stream-lined dependency management system still has this problem, is it realistic for Go modules to solve the problem in its first year?

Pardon my incorrect terminology above ... I guess what I was trying to say is that if a repository can be implicitly considered a module for require purposes, it feels like you should be able to make the same implicit conversion if you want to ban it.

A couple more good ideas for alternate words for ban are exclude and blacklist.

@mark-rushakoff, you can already use an exclude directive or GOPROXY to forbid entire modules. This proposal seems to focus on individual packages instead.

@smoyer64, as @thepudds and @heschik note, this feature is not a good fit for the go.mod file: the go.mod file operates on modules, not packages.

.goimportsignore seems like the right tool for this. Consider filing a proposal to make goimports look for a .goimportsignore file at the module root instead of just GOPATH/src.

@bcmills From the discussion above, I agree that's the correct solution to my problem. I'll submit the bug over there but wanted to thank you all for indulging me and for the productive discussion.

I prefer refuse and
I would like to add the case for local packages.
Example: autogenerated packages, buildignored packages:

module github.com/example/example

go 1.12

require (
	github.com/sirupsen/logrus v1.4.2
        ...
)

refuse (
        github.com/example/local/autogenerated
        github.com/example/local/buildignored
)