7 ms·

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 to

by syvolt 2y ago

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.

jamietanna 2y ago
Yeah, I'm still rather excited about it, but less-so given it /does/ impact the `go.mod` for consumers
movedx 2y ago
What solution would you propose?
- rplnt 2y ago
  At least a comment if not its own section.
arccy 2y ago
There's module graph pruning https://go.dev/ref/mod#graph-pruning https://go.dev/ref/mod#graph-pruning
cirwin 2y ago
Primary contributor to the feature here. 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.
- syvolt 2y ago
  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?
  - wakawaka28 2y ago
    >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.
    - verdverm 2y ago
      In addition, a good dependency security scanning tool can analyze reachability to answer this question for you
      - syvolt 2y ago
        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.
        verdverm 2y ago
        I'm speaking of tools and processes independent of this "go tool" stuff that we already use in our CI pipelines Big fan of Dagger over this go tool thing I generally loath the use of comments for things other than comments
- caust1c 2y ago
  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.
  - cirwin 2y ago
    `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.
    - caust1c 2y ago
      Thanks for the explanation and contribution! Very much appreciated :-)
- eadmund 2y ago
  > 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 …
deleted 2y ago
[deleted]

by syvolt 2y ago

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.

jamietanna 2y ago

Yeah, I'm still rather excited about it, but less-so given it /does/ impact the `go.mod` for consumers

movedx 2y ago

What solution would you propose?

rplnt 2y ago
At least a comment if not its own section.

arccy 2y ago

There's module graph pruning https://go.dev/ref/mod#graph-pruning https://go.dev/ref/mod#graph-pruning

cirwin 2y ago

Primary contributor to the feature here. 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.

syvolt 2y ago
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?
- wakawaka28 2y ago
  >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.
  - verdverm 2y ago
    In addition, a good dependency security scanning tool can analyze reachability to answer this question for you
    - syvolt 2y ago
      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.
      - verdverm 2y ago
        I'm speaking of tools and processes independent of this "go tool" stuff that we already use in our CI pipelines Big fan of Dagger over this go tool thing I generally loath the use of comments for things other than comments
caust1c 2y ago
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.
- cirwin 2y ago
  `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.
  - caust1c 2y ago
    Thanks for the explanation and contribution! Very much appreciated :-)
eadmund 2y ago
> 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 …

deleted 2y ago

[deleted]