3 ms·

damn thats a big ass list of imports: https://github.com/caddyserver/caddy/blob/master/go.sum https://github.com/caddyserver/caddy/blob/master/go.sum

by 38 2y ago

bigyikes 2y ago
that’s nothing compared to the average package-lock.json! it actually doesn’t seem like that long of a list if you only consider one version per library
- vaughnegut 2y ago
  Also go.sum is roughly equivalent to your package-lock.json. go.mod would be the package.json equivalent
- 38 2y ago
  Is this a joke comment?
francislavoie 2y ago
go.sum is not imports. It's a checksums file, it's used in determining which versions of things to pin to. It doesn't necessarily mean all of those things end up in the final binary. See https://go.dev/ref/mod#go-sum-files https://go.dev/ref/mod#go-sum-files. You can run `caddy build-info` to see everything that is a dependency in the build. From my count, a vanilla build of Caddy v2.8.0 has 122 packages as dependencies (many of which are indirect).
- 38 2y ago
  > You can run `caddy build-info` Or just go version -m > 122 packages That's still a lot > many of which are indirect) That means literally nothing. Indirect still gets built, indirect still in the exe.
  - francislavoie 2y ago
    I think you underestimate how much a general purpose webserver needs to be able to do. Do you have any specific criticism about the list of dependencies? What do you think is actually unnecessary?
    - vundercind 2y ago
      Not the original poster, but at a glance, oauth, sso, and a whole bunch of PostgreSQL(?!) packages stand out as surprising things to see in a web server.
      - francislavoie 2y ago
        If you actually run `caddy build-info`, you'll see that none of those are actually in the build. You can't just look at go.sum, like I explained above.
mholt 2y ago
(Dividing line count by 2) It looks like we currently rely on about 322 direct or transitive dependencies. It's worth noting many of those are test-only dependencies. A lot of the /x/ packages are repeated, just different versions; and I believe -- if my understanding is right -- a lot of these are only used for checksum verification, not necessarily a manifest of what is compiled into the binary. But, the point remains, dependencies can bloat quickly, which is why we went with such a modular architecture for Caddy 2.
infogulch 2y ago
This is a bit tangential... I recently noticed that a module that is split into packages that have distinct subsets of dependencies will only add transitives to your own go.mod based on the packages that you actually use. This tripped me up trying to minimize dependencies for a library by splitting it into a separate repo from the rest of the application, but this is totally unnecessary (and annoying to manage). Go modules are pretty good.

damn thats a big ass list of imports: https://github.com/caddyserver/caddy/blob/master/go.sum https://github.com/caddyserver/caddy/blob/master/go.sum

by 38 2y ago

damn thats a big ass list of imports: https://github.com/caddyserver/caddy/blob/master/go.sum https://github.com/caddyserver/caddy/blob/master/go.sum

bigyikes 2y ago

that’s nothing compared to the average package-lock.json! it actually doesn’t seem like that long of a list if you only consider one version per library

vaughnegut 2y ago
Also go.sum is roughly equivalent to your package-lock.json. go.mod would be the package.json equivalent
38 2y ago
Is this a joke comment?

francislavoie 2y ago

go.sum is not imports. It's a checksums file, it's used in determining which versions of things to pin to. It doesn't necessarily mean all of those things end up in the final binary. See https://go.dev/ref/mod#go-sum-files https://go.dev/ref/mod#go-sum-files. You can run `caddy build-info` to see everything that is a dependency in the build. From my count, a vanilla build of Caddy v2.8.0 has 122 packages as dependencies (many of which are indirect).

38 2y ago
> You can run `caddy build-info` Or just go version -m > 122 packages That's still a lot > many of which are indirect) That means literally nothing. Indirect still gets built, indirect still in the exe.
- francislavoie 2y ago
  I think you underestimate how much a general purpose webserver needs to be able to do. Do you have any specific criticism about the list of dependencies? What do you think is actually unnecessary?
  - vundercind 2y ago
    Not the original poster, but at a glance, oauth, sso, and a whole bunch of PostgreSQL(?!) packages stand out as surprising things to see in a web server.
    - francislavoie 2y ago
      If you actually run `caddy build-info`, you'll see that none of those are actually in the build. You can't just look at go.sum, like I explained above.

mholt 2y ago

(Dividing line count by 2) It looks like we currently rely on about 322 direct or transitive dependencies. It's worth noting many of those are test-only dependencies. A lot of the /x/ packages are repeated, just different versions; and I believe -- if my understanding is right -- a lot of these are only used for checksum verification, not necessarily a manifest of what is compiled into the binary. But, the point remains, dependencies can bloat quickly, which is why we went with such a modular architecture for Caddy 2.

infogulch 2y ago

This is a bit tangential... I recently noticed that a module that is split into packages that have distinct subsets of dependencies will only add transitives to your own go.mod based on the packages that you actually use. This tripped me up trying to minimize dependencies for a library by splitting it into a separate repo from the rest of the application, but this is totally unnecessary (and annoying to manage). Go modules are pretty good.