Comment by richid

Comment by richid a day ago

4 replies

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 a day ago

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

  • mdaniel a day ago

    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 a day ago

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

      • mdaniel a day ago

        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