[richid]

I've been out of the Python game for a while but I'm not surprised there is yet another tool on the market to handle this.

You really come to appreciate when these batteries are included with the language itself. That Go binary will _always_ run but that Python project won't build in a few years.

[pjmlp]

Unless it made use of CGO and has dynamic dependencies, always is a bit too much.

[mdaniel]

Or the import path was someone's blog domain that included a <meta> reference to the actual github repo (along with the tag, IIRC) where the source code really lives. Insanity

[pjmlp]

I never understood the mentality to have SCM urls as package imports directly on the source code.

[mdaniel]

Well, that's the problem I was highlighting - golang somehow decided to have the worst of both worlds: arbitrary domains in import paths and then putting the actual ref of the source code ... elsewhere

  import "gopkg.in/yaml.v3" // does *what* now?

  curl https://gopkg.in/yaml.v3?go-get=1 | grep github
  <meta name="go-source" content="gopkg.in/yaml.v3 _ https://github.com/go-yaml/yaml/tree/v3.0.1{/dir} https://github.com/go-yaml/yaml/blob/v3.0.1{/dir}/{file}#L{line}">

oh, ok :-/

I would presume only a go.mod entry would specify whether it really is v3.0.0 or v3.0.1

Also, for future generations, don't use that package https://github.com/go-yaml/yaml#this-project-is-unmaintained