5 ms·

I have a lot of bad things to say about Gos module system, but this ain't one of them. With this system you don't need an account somewhere to publish a package

I have a lot of bad things to say about Gos module system, but this ain't one of them. With this system you don't need an account somewhere to publish a package and you still get to use GitHub, Gitlab, etc. without your module URL being dependent on them. If you consider alternative systems with accounts, if you loose access to the underlying email, you may be out of luck, too. Or in the case of Rust/crates.io, if you delete/switch your Github account you can't log in anymore either.

cookiengineer 3y ago
What I like about the go.mod file is that it easily allows to remap go modules to local path folders. This way I can have a backup of the dependencies wherever I want, even when not using "go mod vendor" (which I like also a lot tbh). So I don't understand the critic in the article, you cannot solve this problem efficiently other than putting everything on a blockchain, which will waste a lot of hard drive space.
IshKebab 3y ago
I'm curious what bad things you have to say about it. I haven't actually used it but my impression from reading the design docs was that it's the best module design so far. Better than Rust for example.
- janosdebugs 3y ago
  My main gripe with it is the missing separation between test and prod dependencies. Let's say you work on program A, which depends on library B. Library B uses library C as a test dependency. It shouldn't have any effect on A whatsoever and should not even be downloaded. Yet it is. Apart from the obvious bandwidth and storage space wasted, this is also a problem when compiling an SBOM (Software Bill of Materials) and when scanning for vulnerable dependencies. There is simply no way to tell if your Go binary is vulnerable simply by looking at the go.mod/go.sum file, you have to build and analyze the binary and hope that everything went well. Same for compiling NOTICE files for license compliance. (wink wink Apache license) This isn't an unknown or unsolved problem either, Maven solved this ages ago. There are also some minor nitpicks, such as their absolute requirement to do path-based semantic versioning from v2, but not from v1 or v0. If you change anything, but absolutely anything that's publicly visible, you must increase the minor version of the library you are publishing or you will have a really bad time. If you want to publish both a library and an application, you have to either version them with ridiculous version numbers, or you have to split the two.
  - Thaxll 3y ago
    What's the problem that your tests depends on lib C, if it's using it it makes sense that the main program depends on it. Go test are part of the main program, if you want them separated then create another module that import a and c for testing.
    - janosdebugs 3y ago
      It's not _my_ tests that depend on C, but B's tests. I don't maintain B, nor do I care for its tests. They shouldn't be in my dependency tree at all. This is a problem because every time C has a vulnerability, you get a deluge of vulnerability scanner alerts or Dependabot pull requests to update it, even though your application has nothing to do with C. If anyone has a solution for this, I'd really love to hear it because it consumes a silly amount of time to deal with bogus vulnerability alerts.
- deleted 3y ago
  [deleted]

cookiengineer 3y ago

What I like about the go.mod file is that it easily allows to remap go modules to local path folders. This way I can have a backup of the dependencies wherever I want, even when not using "go mod vendor" (which I like also a lot tbh). So I don't understand the critic in the article, you cannot solve this problem efficiently other than putting everything on a blockchain, which will waste a lot of hard drive space.

IshKebab 3y ago

I'm curious what bad things you have to say about it. I haven't actually used it but my impression from reading the design docs was that it's the best module design so far. Better than Rust for example.

janosdebugs 3y ago
My main gripe with it is the missing separation between test and prod dependencies. Let's say you work on program A, which depends on library B. Library B uses library C as a test dependency. It shouldn't have any effect on A whatsoever and should not even be downloaded. Yet it is. Apart from the obvious bandwidth and storage space wasted, this is also a problem when compiling an SBOM (Software Bill of Materials) and when scanning for vulnerable dependencies. There is simply no way to tell if your Go binary is vulnerable simply by looking at the go.mod/go.sum file, you have to build and analyze the binary and hope that everything went well. Same for compiling NOTICE files for license compliance. (wink wink Apache license) This isn't an unknown or unsolved problem either, Maven solved this ages ago. There are also some minor nitpicks, such as their absolute requirement to do path-based semantic versioning from v2, but not from v1 or v0. If you change anything, but absolutely anything that's publicly visible, you must increase the minor version of the library you are publishing or you will have a really bad time. If you want to publish both a library and an application, you have to either version them with ridiculous version numbers, or you have to split the two.
- Thaxll 3y ago
  What's the problem that your tests depends on lib C, if it's using it it makes sense that the main program depends on it. Go test are part of the main program, if you want them separated then create another module that import a and c for testing.
  - janosdebugs 3y ago
    It's not _my_ tests that depend on C, but B's tests. I don't maintain B, nor do I care for its tests. They shouldn't be in my dependency tree at all. This is a problem because every time C has a vulnerability, you get a deluge of vulnerability scanner alerts or Dependabot pull requests to update it, even though your application has nothing to do with C. If anyone has a solution for this, I'd really love to hear it because it consumes a silly amount of time to deal with bogus vulnerability alerts.
deleted 3y ago
[deleted]