3 ms·

So it's just dev-dependencies?

by remram 2y ago

jamietanna 2y ago
Yep, that's the intent
the_gipsy 2y ago
lol yea
silverwind 2y ago
Yes, except it does not support version ranges.
- verdverm 2y ago
  Go uses Minimum Version Selection (MVS) instead of a SAT solver. There are no ranges in any go dependency specifications. It's actually a very simple and elegant algorithm for dependency version selection https://research.swtch.com/vgo-mvs https://research.swtch.com/vgo-mvs
  - 8n4vidtmkvmk 2y ago
    > Minimal version selection assumes that each module declares its own dependency requirements: a list of minimum versions of other modules. Modules are assumed to follow the import compatibility rule—packages in any newer version should work as well as older ones—so a dependency requirement gives only a minimum version, never a maximum version or a list of incompatible later versions. That sounds like a non-starter. You almost never want to to unintentionally 'upgrade' to the next 'major' ver. There's also occasionally broken or hacked/compromised minor vers.
    - arccy 2y ago
      thankfully major versions in go have different names (module, module/v2, module/v3) enforced by tooling, so you'll never upgrade to the next major (except v0 -> v1).
nikolayasdf123 2y ago
a bit worse. it is all mixed up. to keep separate dependency tree for tools need use old approach with go.mod. it is actually even worse now.
- nikolayasdf123 2y ago
  UPD: 1. it is single tree 2. BUT tools will not propagate through the dependency tree downstream due to go module pruning check this comment: https://github.com/golang/go/issues/48429#issuecomment-2618445287 https://github.com/golang/go/issues/48429#issuecomment-26184... official docs: https://tip.golang.org/doc/modules/managing-dependencies#tools https://tip.golang.org/doc/modules/managing-dependencies#too... > Due to module pruning, when you depend on a module that itself has a tool dependency, requirements that exist just to satisfy that tool dependency do not usually become requirements of your module.
  - remram 2y ago
    "usually"?

So it's just dev-dependencies?

by remram 2y ago

So it's just dev-dependencies?

jamietanna 2y ago

Yep, that's the intent

the_gipsy 2y ago

lol yea

silverwind 2y ago

Yes, except it does not support version ranges.

verdverm 2y ago
Go uses Minimum Version Selection (MVS) instead of a SAT solver. There are no ranges in any go dependency specifications. It's actually a very simple and elegant algorithm for dependency version selection https://research.swtch.com/vgo-mvs https://research.swtch.com/vgo-mvs
- 8n4vidtmkvmk 2y ago
  > Minimal version selection assumes that each module declares its own dependency requirements: a list of minimum versions of other modules. Modules are assumed to follow the import compatibility rule—packages in any newer version should work as well as older ones—so a dependency requirement gives only a minimum version, never a maximum version or a list of incompatible later versions. That sounds like a non-starter. You almost never want to to unintentionally 'upgrade' to the next 'major' ver. There's also occasionally broken or hacked/compromised minor vers.
  - arccy 2y ago
    thankfully major versions in go have different names (module, module/v2, module/v3) enforced by tooling, so you'll never upgrade to the next major (except v0 -> v1).

nikolayasdf123 2y ago

a bit worse. it is all mixed up. to keep separate dependency tree for tools need use old approach with go.mod. it is actually even worse now.

nikolayasdf123 2y ago
UPD: 1. it is single tree 2. BUT tools will not propagate through the dependency tree downstream due to go module pruning check this comment: https://github.com/golang/go/issues/48429#issuecomment-2618445287 https://github.com/golang/go/issues/48429#issuecomment-26184... official docs: https://tip.golang.org/doc/modules/managing-dependencies#tools https://tip.golang.org/doc/modules/managing-dependencies#too... > Due to module pruning, when you depend on a module that itself has a tool dependency, requirements that exist just to satisfy that tool dependency do not usually become requirements of your module.
- remram 2y ago
  "usually"?