3 ms·

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

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 2y ago
It does sound painful to have to update a package version by updating an import string in hundreds of files
- pavlov 2y ago
  #define SDK_VER 1.2.3
- klodolph 2y ago
  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.
  - earthboundkid 2y ago
    You can do it using gofmt, by writing gofmt -w -r '"github.com/abc/def" -> "github.com/abc/def/v2"' . That won't do subpackages though.
  - nolok 2y ago
    Now add complex versionning and optional dependancy and dev level dependancy and... You'll get what he means. Every language starts the way you describe, then needs are added.
    - klodolph 2y ago
      I’ve been a Go programmer for many years now, and I don’t “get what he means”. Am I stupid? Maybe you could elaborate. What is complex versioning? In Go, you specify a minimum minor version, and breaking changes change the package name & import path (or they’re supposed to). Why would I want complex versioning? The underlying problem that versioning solves is complicated, but that doesn’t mean you benefit from a complex versioning scheme.
klodolph 2y ago
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.)

stevebmark 2y ago

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

pavlov 2y ago
#define SDK_VER 1.2.3
klodolph 2y ago
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.
- earthboundkid 2y ago
  You can do it using gofmt, by writing gofmt -w -r '"github.com/abc/def" -> "github.com/abc/def/v2"' . That won't do subpackages though.
- nolok 2y ago
  Now add complex versionning and optional dependancy and dev level dependancy and... You'll get what he means. Every language starts the way you describe, then needs are added.
  - klodolph 2y ago
    I’ve been a Go programmer for many years now, and I don’t “get what he means”. Am I stupid? Maybe you could elaborate. What is complex versioning? In Go, you specify a minimum minor version, and breaking changes change the package name & import path (or they’re supposed to). Why would I want complex versioning? The underlying problem that versioning solves is complicated, but that doesn’t mean you benefit from a complex versioning scheme.

klodolph 2y ago

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.)