6 ms·

Go has had an equally bad packaging experience. Kubernetes - which is one of the biggest projects built in go - has been struggling with dependency and package

Go has had an equally bad packaging experience. Kubernetes - which is one of the biggest projects built in go - has been struggling with dependency and package management. Here's the CTO of Rancher commenting on his struggles https://twitter.com/ibuildthecloud/status/1187529098886664193?s=19 https://twitter.com/ibuildthecloud/status/118752909888666419... https://twitter.com/ibuildthecloud/status/1187538210152308736?s=19 https://twitter.com/ibuildthecloud/status/118753821015230873... This is not trivial stuff..and it shouldn't be trivialised into a go vs python flamewar. Because it can't be.

throwaway894345 7y ago
I've used Python and Go extensively. Go's packaging story has a few rough edges, but Python's is an impenetrable maze of competing tools that each purport to address others' major hidden pitfalls. To work with Python packages, you have to pick the right subset of these technologies to work with, and you'll probably have to change course several times because all of them have major hidden pitfalls: * wheels * eggs * pex * shiv * setuptools * sdist * bdist * virtualenv * pipenv * pyenv * sys.path * pyproject.toml * pip * pipfile * poetry * twine * anaconda To work with Go: * Publish package (including documentation): git tag $VERSION && git push $VERSION * Add a dependency: add the import declaration in your file and `go build` * Distribution: Build a static binary for every target platform and send it to whomever. No need to have a special runtime (or version thereof) installed nor any kind of virtual environment nor any particular set of dependencies.
- ForHackernews 7y ago
  Yeah, until github is unreachable and the entire Go universe grinds to an immediate halt because nothing will build. Python packaging is a mess, but Go doesn't even bother. "Just download from some VCS we'll pretend is 100% reliable and compile from source" is not a packaging solution.
  - kelnos 7y ago
    How is that any different than the entire Python universe grinding to an immediate halt if there's an issue with pypi.python.org? (Hint: it's not.) You can certainly debate the difference in uptime between specific services; I don't know either way, but if you told my that PyPi had higher uptime than GitHub, I'd believe you... but that's kinda missing the point. If you depend on an online service to host your release artifacts, if and when that service goes down, it's gonna hurt. Meanwhile, Python's packaging wars continue to rage on. Go's is simple: a release is a tag in a VCS repository. I'm sure there are issues with that as well, but that should come as no surprise, considering there are issues with literally every packaging solution. At any rate, there's little moral difference between downloading a tarball (or a wheel, or... whatever), vs. pulling a tag from a git repo. It requires equal levels of trust to believe that no one has tampered with prior releases in both cases. I'd like to also point out that I don't have a dog in this race. I've done a little Go here and there, but frankly I don't like the ergonomics of the language too much, so I stay away from it. I've done (and continue to do) a decent amount of Python. I like the language, but tend to prefer strongly-typed, functional languages, and languages with performant runtimes, so I tend to only use it for smaller projects.
    - ForHackernews 7y ago
      You can trivially run your own local PyPI mirror or install packages directly from some other source (e.g. S3 bucket, LAN storage). Is there a way to do that for Go? If so, I've never seen it done.
      - morelisp 7y ago
        It's possibly as of the proxy in Go 1.13, but this was not well-documented, suffers from competing implementations, and introduced in a way that probably broke more builds than it helped.
      - jatone 7y ago
        yes you just vendor your dependencies. go has support for a proxy system, tooling is still immature though.
- joshuamorton 7y ago
  You're combining multiple problems: maintaining a package for redistribution, and using packages. For the second, the much more common case, 2/3 of the things on your list are irrelevant.
  - throwaway894345 7y ago
    For either case, Python’s story is more complex than Go’s.

throwaway894345 7y ago

I've used Python and Go extensively. Go's packaging story has a few rough edges, but Python's is an impenetrable maze of competing tools that each purport to address others' major hidden pitfalls. To work with Python packages, you have to pick the right subset of these technologies to work with, and you'll probably have to change course several times because all of them have major hidden pitfalls: * wheels * eggs * pex * shiv * setuptools * sdist * bdist * virtualenv * pipenv * pyenv * sys.path * pyproject.toml * pip * pipfile * poetry * twine * anaconda To work with Go: * Publish package (including documentation): git tag $VERSION && git push $VERSION * Add a dependency: add the import declaration in your file and `go build` * Distribution: Build a static binary for every target platform and send it to whomever. No need to have a special runtime (or version thereof) installed nor any kind of virtual environment nor any particular set of dependencies.

ForHackernews 7y ago
Yeah, until github is unreachable and the entire Go universe grinds to an immediate halt because nothing will build. Python packaging is a mess, but Go doesn't even bother. "Just download from some VCS we'll pretend is 100% reliable and compile from source" is not a packaging solution.
- kelnos 7y ago
  How is that any different than the entire Python universe grinding to an immediate halt if there's an issue with pypi.python.org? (Hint: it's not.) You can certainly debate the difference in uptime between specific services; I don't know either way, but if you told my that PyPi had higher uptime than GitHub, I'd believe you... but that's kinda missing the point. If you depend on an online service to host your release artifacts, if and when that service goes down, it's gonna hurt. Meanwhile, Python's packaging wars continue to rage on. Go's is simple: a release is a tag in a VCS repository. I'm sure there are issues with that as well, but that should come as no surprise, considering there are issues with literally every packaging solution. At any rate, there's little moral difference between downloading a tarball (or a wheel, or... whatever), vs. pulling a tag from a git repo. It requires equal levels of trust to believe that no one has tampered with prior releases in both cases. I'd like to also point out that I don't have a dog in this race. I've done a little Go here and there, but frankly I don't like the ergonomics of the language too much, so I stay away from it. I've done (and continue to do) a decent amount of Python. I like the language, but tend to prefer strongly-typed, functional languages, and languages with performant runtimes, so I tend to only use it for smaller projects.
  - ForHackernews 7y ago
    You can trivially run your own local PyPI mirror or install packages directly from some other source (e.g. S3 bucket, LAN storage). Is there a way to do that for Go? If so, I've never seen it done.
    - morelisp 7y ago
      It's possibly as of the proxy in Go 1.13, but this was not well-documented, suffers from competing implementations, and introduced in a way that probably broke more builds than it helped.
    - jatone 7y ago
      yes you just vendor your dependencies. go has support for a proxy system, tooling is still immature though.
joshuamorton 7y ago
You're combining multiple problems: maintaining a package for redistribution, and using packages. For the second, the much more common case, 2/3 of the things on your list are irrelevant.
- throwaway894345 7y ago
  For either case, Python’s story is more complex than Go’s.