4 ms·

I was likewise shocked at how good go compared to python in this regard. Resolve your deps once, at build time, and you're done. Compare that to dealing with

I was likewise shocked at how good go compared to python in this regard. Resolve your deps once, at build time, and you're done. Compare that to dealing with the externalized deps that is deploying a python app on a machine that might have the correct version of python and all dependencies, or not. virtualenv? good luck. You end up bringing in docker and other tools just to deal with it. But what do you do if the machine is locked down by corporate IT and they don't allow docker or the installation of other python deps?

orf 8y ago
Pipenv.
- weberc2 8y ago
  We use pipenv, but it's been buggy and quarelsome so far. I like what it promises to do, but so far my experiences with Go modules have been better (to my surprise, given how much newer Go modules are than pipenv).
collinvandyck76 8y ago
> at build time Unless you're using CGO, in which case you still have to make sure your target environment has the shared libraries your bindings will make calls to.
- deleted 8y ago
  [deleted]
- weberc2 8y ago
  Isn't this true for Python as well?
- bitwalker 8y ago
  Unless you statically link your dependencies, but that comes with its own can of worms.
mylons 8y ago
good? go package management is awful. it makes tools like searching through a git repo a chore because all of the source code for your module is in the repo too. the OP was pointing out how far behind go is behind something like python. if you really wanted to, you could so something exactly like go is doing in python and create a virtual environment with all of your packages and version of python and ship it. there are also ways to build binaries from python. if your machine is locked down by corporate IT, you use a virutal environment
jacques_chester 8y ago
> Resolve your deps once, at build time, and you're done. I have ... rarely had this experience. Every go package manager has found new and frankly fascinating ways to lead me into a corner where I think I have committed and pushed working code, but which causes highly-visible CI barfing. I should add as an aside: I've done two tours of duty as a Cloud Foundry Buildpacks maintainer. Everyone's package system sucks, but some suck a lot less. * Maven is basically sane if used with levelled starters. Otherwise it's a preview of fighting the Many-Tentacled Ones of the Deeply Nested Dependency Graph using nothing but a dull butter knife held upside-down. * Gradle is the worst allergic reaction to XML in history. * NPM used to have amazing bugs and missing features but has laboriously, slowly improved. * Python is about whether you hit the sweet spot of the particular packaging system you use. * PHP is a mess, unless you use Composer, in which case you're still stuck with the weird reality that PHP's package system is really a mix of in-process modules which need to be compiled and slabs of plain old PHP. * .NET Core had what seems like a deliberate policy to come up with the most confusing naming and versioning scheme humanly possible and was wildly successful at doing so. Oh, and no canonical reference for versions. None. Apparently this improved but it was hell on earth. * Golang. A new package manager every ten minutes. A different vendoring model, different assembly model, different bugs, every damn week. Only Bundler is basically sane. We hit lots of corner cases but for the 20/80 cases it essentially worked.
- skywhopper 8y ago
  I think the point above was that once the binary is built you don’t have to worry about maintaining the exact same libraries on the server where they might be competing/mixing with various incompatible versions of shared libraries for Python or Ruby or whatever. That said, yes this is a shameful hole in the golang world (caused by the project leads’ inside-Google myopia) but I’m glad they are finally addressing it at this level of integration. And despite a few oddities it looks pretty solid.
  - jacques_chester 8y ago
    > once the binary is built My view is that if it can't be built from scratch in a cleanroom environment -- ie, in CI or a buildpacks stager -- it can't be built. This goes for container images too. The amount of "works on my machine" and "where's Gerald? this module only builds on his laptop" I saw as a consultant was depressing. Speaking of containers, though: they solved the contending-interpreters problem quite handily. Cloud Foundry has used containerisation since before Docker existed and it really shines for buildpack usage. We started with Heroku's buildpacks, which had to deal with the nightmare of a pre-container world and showed all the pain of it. There was a great deal of stuff we just didn't have to care about and we later rewrote the bulk of the buildpacks to jettison all the stuff we didn't need. It's all come full circle: Heroku now use containerisation and both Heroku and Cloud Foundry will soon be adopting jointly-developed buildpacks-lifecycle code.
deleted 8y ago
[deleted]

orf 8y ago

Pipenv.

weberc2 8y ago
We use pipenv, but it's been buggy and quarelsome so far. I like what it promises to do, but so far my experiences with Go modules have been better (to my surprise, given how much newer Go modules are than pipenv).

collinvandyck76 8y ago

> at build time Unless you're using CGO, in which case you still have to make sure your target environment has the shared libraries your bindings will make calls to.

deleted 8y ago
[deleted]
weberc2 8y ago
Isn't this true for Python as well?
bitwalker 8y ago
Unless you statically link your dependencies, but that comes with its own can of worms.

mylons 8y ago

good? go package management is awful. it makes tools like searching through a git repo a chore because all of the source code for your module is in the repo too. the OP was pointing out how far behind go is behind something like python. if you really wanted to, you could so something exactly like go is doing in python and create a virtual environment with all of your packages and version of python and ship it. there are also ways to build binaries from python. if your machine is locked down by corporate IT, you use a virutal environment

jacques_chester 8y ago

> Resolve your deps once, at build time, and you're done. I have ... rarely had this experience. Every go package manager has found new and frankly fascinating ways to lead me into a corner where I think I have committed and pushed working code, but which causes highly-visible CI barfing. I should add as an aside: I've done two tours of duty as a Cloud Foundry Buildpacks maintainer. Everyone's package system sucks, but some suck a lot less. * Maven is basically sane if used with levelled starters. Otherwise it's a preview of fighting the Many-Tentacled Ones of the Deeply Nested Dependency Graph using nothing but a dull butter knife held upside-down. * Gradle is the worst allergic reaction to XML in history. * NPM used to have amazing bugs and missing features but has laboriously, slowly improved. * Python is about whether you hit the sweet spot of the particular packaging system you use. * PHP is a mess, unless you use Composer, in which case you're still stuck with the weird reality that PHP's package system is really a mix of in-process modules which need to be compiled and slabs of plain old PHP. * .NET Core had what seems like a deliberate policy to come up with the most confusing naming and versioning scheme humanly possible and was wildly successful at doing so. Oh, and no canonical reference for versions. None. Apparently this improved but it was hell on earth. * Golang. A new package manager every ten minutes. A different vendoring model, different assembly model, different bugs, every damn week. Only Bundler is basically sane. We hit lots of corner cases but for the 20/80 cases it essentially worked.

skywhopper 8y ago
I think the point above was that once the binary is built you don’t have to worry about maintaining the exact same libraries on the server where they might be competing/mixing with various incompatible versions of shared libraries for Python or Ruby or whatever. That said, yes this is a shameful hole in the golang world (caused by the project leads’ inside-Google myopia) but I’m glad they are finally addressing it at this level of integration. And despite a few oddities it looks pretty solid.
- jacques_chester 8y ago
  > once the binary is built My view is that if it can't be built from scratch in a cleanroom environment -- ie, in CI or a buildpacks stager -- it can't be built. This goes for container images too. The amount of "works on my machine" and "where's Gerald? this module only builds on his laptop" I saw as a consultant was depressing. Speaking of containers, though: they solved the contending-interpreters problem quite handily. Cloud Foundry has used containerisation since before Docker existed and it really shines for buildpack usage. We started with Heroku's buildpacks, which had to deal with the nightmare of a pre-container world and showed all the pain of it. There was a great deal of stuff we just didn't have to care about and we later rewrote the bulk of the buildpacks to jettison all the stuff we didn't need. It's all come full circle: Heroku now use containerisation and both Heroku and Cloud Foundry will soon be adopting jointly-developed buildpacks-lifecycle code.

deleted 8y ago

[deleted]