Good riddance. These days I download a repo and "go build". That's literally it.
I used C/C++ for years, and it was always a nightmare to build something, unless it was completely self contained. When your "packaging" is so bad that everything has to be vendored, that should be a red flag.
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. 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).
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?
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.
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.
(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.
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).
fair enough, but you're also downplaying/omitting the huge dependency cost of React, both server side and client side. so pick your poison.
you're basically saying "I want server side code without having to actually code anything". of course nothing is going to beat react, its an impossible ask
Yep. It marks residential IPs for no good reason and for god knows how long. Cloudflare is way up on the list of companies that have broken the internet. But, hey, free stuff, right?!
Maybe hcaptcha, I've never run into captcha hell with it, unlike Cloudflare and recaptcha. If those two decide you're a bot, you're done, better go change that IP and reset cookies.
> If you put this in its proper term it is "corruption" and you should definitely worry about the legal implications of doing this
you seem to only be thinking about one side of this, the company side. what about the endless amount of normal end users that got caught by some god awful AI, and ignored by a huge tech company and its basically non existing customer service?
sorry, english is not my first language. my point is if a real customer, let's say get blocked on Instagram after an account takeover try to use this service to rescue and unblock and get caught by Meta team, surely will not get their account back because of the unofficial means used to recover the account.
wow great idea, why didn't I think of that
reply