4 ms·
Several reasons: 1. Finding dependencies with tooling now requires parsing code. Luckily Go's syntax is relatively simple and doesn't have conditional includes
by cletus 4y ago
Several reasons:
1. Finding dependencies with tooling now requires parsing code. Luckily Go's syntax is relatively simple and doesn't have conditional includes like C++ does but it'd be better if you could simply inspect a depedency configuration;
2. You're directly importing potentially untrusted code that will often be of the form "github.io/someuser/reponame" so you now have a depedency on some random user's security practices or even just whims (eg making the repo private; IIRC this has happened in the node.js ecosystem);
3. These aren't versioned. You may want to stick to a particular version. A new version may break your code. You should be able to be explicit about that. Now you can "go get" particular versions but how do you specify that such that someone can just check out your code and build it?
4. Managing your own dependency repo (eg in an enterprise environment) is more limited.
- morelisp 4y ago2) doesn’t get better just because you put a name that maps to a url in some XML file. 3) we’re six versions into go.mod by default. Nobody has this problem anymore. 4) Just untrue. Go proxies have been by far the easiest thing to deploy and secure because they’re so transparent in the toolchain.
- icholy 4y agoThe go.mod is the dependency configuration file you're describing.