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.
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?
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.
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?
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.
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.
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.
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.
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.
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.
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