This reminds me of the PIK image format (a precursor to JPEG XL) whose name happens to be a word for penis in some languages[0]. In the present case "SPH" is a kink/fetish term meaning "Small Penis Humiliation"[1]. I don't know how many people would think of that, though.
I am not sure if the lesson is to try harder to avoid offence, or live with the fact that words can have multiple meanings and we can be "professional" enough to ignore some of those meanings in some contexts.
I have tested it and probably will use it but the fact that it pollutes your go.mod's indirect dependency list (without any distinction indicating it's for a tool) is very annoying.
We went back on forth on this a lot, but it boiled down to wanting only one dependency graph per module instead of two. This simplifies things like security scanners, and other workflows that analyze your dependencies.
A `// tool` comment would be a nice addition, it's probably not impossible to add, but the code is quite fiddly.
Luckily for library authors, although it does impact version selection for projects who use your module; those projects do not get `// indirect` lines in their go.mod because those packages are not required when building their module.
Thank you for working on it. It is a nice feature and still better than alternatives.
I'm not a library author and I try to be careful about what dependencies I introduce to my projects (including indirect dependencies). On one project, switching to `go tool` makes my go.mod go from 93 lines to 247 (excluding the tools themselves) - this makes it infeasible to manually review.
If I'm only using a single feature of a multi-purpose tool for example, does it matter to me that some unrelated dependency of theirs has a security issue?
>If I'm only using a single feature of a multi-purpose tool for example, does it matter to me that some unrelated dependency of theirs has a security issue?
How is anyone supposed to know whether there's an issue or not? To simplify things, if you use the tool and the dependency belongs to the tool, then the issue can affect you. Anything more advanced than that requires analyzing the code.
What if I'm already using techniques, such as sandboxing, to prevent the tools from doing anything unexpected? Why bring this entire mess of indirect dependencies into my project if I'm just using a tool to occasionally analyze my binary's output size? Or a tool to lint my protobuf files?
If it's a build dependency, then you have to have it. If you don't like the size of the tool then take it up with the authors. I'm not a Go programmer by the way, this is all just obvious to me.
The functionality we're discussing can be used for tools that are not build dependencies. They may be important for your project and worth having contributors be on the same version but not part of the build.
It will still add the dependencies of those tools as indirect dependencies to your go.mod file, that is what's being discussed.
If you use the tool to develop your project then it is basically a build dependency. That is a sweeping generalization, but it's essentially correct in most cases.
That is a bit much to ask for IMO. In any case, the project may not be aware of how any given developer will use the tool. So who is to say that if you change the order of two parameters to the tool, the tool might not take a different path and proceed to hack your computer? You really don't want any of this problem. What you should ask for is for the tools' dependencies to be listed separately, and for each tool to follow the Unix philosophy of "do one thing well."
There is a lot of merit to this statement, as applied to `go tool` usage and to security scanning. Just went through a big security vendor analysis and POCs. In the middle I saw Filippo Valsorda post [1] about false positives from the one stop shops, while govulncheck (language specific) did not have them. At the same time, there was one vendor who did not false positive with the reachability checks on vulns. While not always as good, one-stop-shops also add value by removing a lot of similar / duplicated work. Tradeoffs and such...
The similar/duplicated stuff can be rolled into libraries. Just don't make the libraries too big lol. I suspect there's less duplicated stuff than you think. Most of it would be stuff related to parsing files and command parameters, I guess.
Reachability analysis on a tool that could be called by something outside of the project? We're talking about tools here after all - anything that can run `go tool` in that directory can call it. The go.mod tool entry could just be being used for versioning.
it probably doesn't, and good vulnerability scanners like govulncheck from the go team won't complain about them, because they're unreachable from your source code.
now, do you care about some development tool you're running locally has a security issue? if yes, you needed to update anyway, if not, nothing changes.
> it boiled down to wanting only one dependency graph per module instead of two
Did you consider having tool be an alias for indirect? That would have kept a single dependency graph per module, while still enabling one reading one’s go.mod by hand rather than using ‘go mod’ to know where each dependency came from and why?
I know, a random drive-by forum post is not the same as a technical design …
Having not looked at it deeply yet, why require building every time it's invoked? Is the idea to get it working then add build caching later? Seems like a pretty big drawback (bigger than the go.mod pollution, for me). Github runners are sllooooow so build times matter to me.
`go tool` doesn't require a rebuild, but it does checking that the tool is up-to-date (which requires doing at least a bit of work).
This is one of the main advantages of using `go tool` over the "hope that contributors to have the right version installed" approach. As the version of the tool required by the project evolves, it continues to work.
Interestingly, when I was first working on the proposal, `go run` deliberately did not cache the built binary. That meant that `go tool` was much faster because it only had to do the check instead of re-running the `link` step. In Go 1.24 that was changed (both to support `go tool`, but also for some other work they are planning) so this advantage of `go tool` is not needed anymore.
That seems infinitely better than the status quo. Having unnecessary procedures is much worse. With the former you can go to another doctor, with the latter they'll just run up your bill until you're broke or dead unless you're one of the exceedingly rare few who gets medical advice from multiple doctors (most can't afford that or do not have alternative in-network doctors).
Hacker News, where hackers beg a trillion dollar company to keep not allowing them to create apps on their own hardware without having to go through a bureaucratic process of uploading it to a store. You know, as hackers do.
I agree and I think the damage to humanity that the anti-nuclear movement has done is incalculable. So many years of progress have been missed out on... and while some of it was due to greed (fossil fuel industry funding), most of it was just misplaced fear, whether propaganda induced or from an inability to see the full picture.
The anti-nuclear movement is also still alive and doing well
but at this point it's like arguing over spilled milk, the damage is mostly done and a lot of is irreversible. We can try to salvage nuclear but we've already regressed to further impure sources in some countries so progress seems unlikely.
I wish more people knew about fraud protection and how not to trigger it. If you want to pay in an unusual way, ask support if it's allowed or causes issues.
If you just try and imitate the average customer you will almost always be on the happy path, but ordering multiple books with multiple cards in a short period... I think that would trigger any decent fraud protection and not just at Amazon scale.
For most services (I'd assume even Amazon) they likely wouldn't be able to tell you what would trip their fraud detection. Most of the time fraud detection happens at the payment processor or issuing bank level, and even if it is detected directly by the service, usually the support department doesn't have much access to the fraud department, and fraud departments are usually very protective around details of how they detect fraud.
To be fair, it seems like their only option was to look like someone running stolen credit card numbers, due to how two systems outside their control worked—the work payment system that issued one card number per transaction; Amazon not letting you buy more than one ebook at a time.
I tried looking for something like this but ended up doing over a month of sales calls and meetings.
One problem is probably that a lot of companies pull enterprise pricing out of their ass (or there's too many confounding factors that make it look like that), and the other big problem was already mentioned, they're trying to maximize your spending.
I've been using Ent for some time on a project and its been quite nice to just be able to write the schema in Go, testing has been a breeze with the enttest package, hooks work well, and everything feels intuitive to me unlike most other ORMs or ORM-adjacent tools.
My preferred package before Ent was Squirrel [1] but I definitely plan to use Ent for future projects.
There is no doubt in my mind that lesser privileged kids get bullied when they get invited to an iPhone texting group and they instantly break all functionality with cheaper Android phones. Apple downplaying teenage (hell even younger now) bullying for profit and people leaping to their defense is disheartening.
Speculatively tying your pet peeve to a serious social problem is an old and tired framing trick. That way if people disagree with your pet peeve, you can retort with “oh, I guess you don’t care about teen suicide?”
It’s obvious and it does little to advance your cause, while trivializing the actual serious problem.
Speculative tie-in? Google's claims are that Apple profits from peer pressure and bullying, I'm not sure but I would think that the people most bullied would be teens and then logically some would commit suicide because of it, I'm sure other bullying would be part of the bullying "package" if that appeases you.
It doesn't have to be RCS but Apple has made clear they don't want any interoperability, so that seems like bad faith.
> There is no doubt in my mind that lesser privileged kids get bullied when they get invited to an iPhone texting group and they instantly break all functionality with cheaper Android phones.
Sample size of one, but I asked my 13 y.o. daughter.
Me:
This guy believes kids get bullied for having Android phones
Daughter:
What guy
Me:
Random guy
As a kid, do people care about the blue vs green bubble thing?
Daughter:
No
Before I knew it happened when you texted an android i thought the green was special
lol
Another data point. I'm from Spain, and the ones who are bullied here are the iPhone users. Vast majority of people are Android users, and iPhone users are seen as snobs. That's among the adults. Nobody here would hand over an iPhone to a kid. It's not hugely expensive, but it's expensive enough.
You think so? It might be a tad dramatic but teens interface with the world through their phones and this purposeless "otherization" can not be having a good effect on society.
A trad dramatic? Ha, it's incredibly dramatic. If it isn't green bubbles, it will be the wrong hair color, the wrong video game tastes, liking the wrong instructor, a million other stupid things. The correct solution is to exacerbate differences within students to the point that cliques are difficult to create due to less in common, and absolutely not attempt to create increased conformity.
Increasing conformity only further increases the obviousness of people's differences, no matter how slight. An extreme example would be Japan, which was so homogenous that discrimination by Blood Type is a thing.
Definitely won't look as pretty as the parent project though but I prefer kong in terms of the actual code you need to write.
[1] https://github.com/alecthomas/kong