[fiedzia]

Some do (Go), but it is really not the best idea. You do want to have one central place where you specify:

- version constraints - source of packages (you may want to host them yourself one day) - any additional metadata (some packages have options or features)

[stevebmark]

It does sound painful to have to update a package version by updating an import string in hundreds of files

[klodolph]

It is not painful in Go.

For example… let’s say you have just plain search-replace and no smart tools. You need to update github.com/abc/def to github.com/abc/def/v2. This is a search-replace operation.

This only happens when packages publish breaking changes. The minor version is stored in go.mod.

[pavlov]

#define SDK_VER 1.2.3

[klodolph]

This is how Go worked in the old days, before modules.

Nowadays, the version constraints are specified in go.mod. Because the fully-qualified package names are used to import them, you can reconstruct go.mod from the sources, assuming that you don’t care about version numbers.

The source code says which packages, the go.mod file says which versions. (Major versions have different import paths.)