6 ms·

I don't get it... Can't you just use a virtualenv? Then there's no worry about namespace pollution or conflicts between dependencies of different projects.

eeZah7Ux 7y ago
This is becoming a parody of software engineering. People are now irrationally scared of using dynamic libraries, OS packages and even directories, like virtualenvs. Instead, a simple solution is replaced with containers, or by rewriting tons of code in the new hyped language. Are we trying to create job security through unnecessary complexity?
- grumpydba 7y ago
  > Are we trying to create job security through unnecessary complexity? As a python/go dev, I can assure you that go is not much more complex. And as a server admin, it's much easier to deploy. It does have drawbacks when compared to python, but it can often be the optimal solution.
  - giancarlostoro 7y ago
    Also a Python dev. I do use VirtualEnv but the other thing is a huge performance boost for small performance intensive projects.
- folkrav 7y ago
  Isolation is merely one utility of containers.
- weberc2 7y ago
  This is the weirdest straw man I've seen in a while. Python, not Go, benefits most from containerization. Installing "Dynamic libraries, OS packages, and even directories like virtualenvs" on target machines is far more complicated than sending a single file. I say all this as the DevOps guy in a Python shop.
theshrike79 7y ago
Installing a full virtualenv with all related libraries just to run one script is kind of ridiculous. The server might have the wrong Python version available (2.x vs 3.x, multiple evolutions of 3.x with big features added in each point release). Et cetera, et cetera. Or you could just do it with bash or a static Go binary and be done with it. Portable, works pretty much everywhere.
- mtberatwork 7y ago
  > The server might have the wrong Python version available That's the point of using virtual environments, so that you can run the Python version and libraries that you need. Also, as of 3.3, Python ships with venv which means you don't need to separately install virtualenv anymore. It's all very portable.
  - tseabra 7y ago
    You'd need to install the right Python version though, and even with something like pyenv you might need to install system packages. It really isn't as portable as one might wish.
    - penagwin 7y ago
      This is my exact situation right now. Our website is made in Django, and we use Pyenv to manage our python versions. We'll likely be going to route of a docker image/ pyenv install script. It takes trial/error to figure out some of the packages you need if they aren't installed already, a single binary would be far easier for sure.
  - oblio 7y ago
    Portable means something else. Portable would mean that I could ship the virtualenv. Python missed the forest for the trees.
  - theshrike79 7y ago
    I still need to have python installed on the machine and download all of the libraries needed. Not all operating systems carry Python >3.3 by default, that would mean installing backports or unofficial repositories on production machines. Or you can use a static binary that just works.
reacharavindh 7y ago
So a virtualenv for every script I want to run? each of that downloading a full Python interpreter and whatever modules that Python script uses? How is this any better than a statically compiled binary? Other than useless additional work and bloat on the servers?
skocznymroczny 7y ago
virtualenv still requires internet access. You'd have to create a venv on destination machine and pip install your packages in. You can't scp a local venv onto destination machine and have it work.
- twic 7y ago
  I am an utter noob at Python packaging, but i would like to learn more, so excuse the basic question, but: why doesn't it work? And is there anything in the ecosystem which is like that, but does work? I had heard that the Python packaging and deployment story had got a lot better in recent years, but this sounds like it still falls far short of table stakes.
  - weberc2 7y ago
    I'm not sure why the Python community can't get it sorted out. We've been using Pipenv because it's one of a few tools that supports lockfiles/reproducible builds, and at the time we chose it, the Python packaging authority was advertising it as the official solution for Python packaging; however, after we were already invested in it, they backpedaled becaused the community realized it was very buggy and super slow (as in "it takes literally half an hour to add or remove or update any dependency"). We're finally getting around to migrating away, and we've settled on Twitter's github.com/pantsbuild/pants which is like Google's Bazel except that it's jankier in every way _except_ that Pants supports Python while Bazel doesn't (Bazel advertises Python support, but it doesn't work as the many Python 3 issues in their issue tracker can attest). The nicest thing about Pants is that it builds pex files (github.com/pantsbuild/pex) which are executable zip files that ship all of your dependencies except the Python interpreter and shared objects. I'm still not very satisfied with this solution, and it's still far, far worse than Go's dependency management and packaging model, but it's a dramatic improvement over Pipenv, virtualenv, etc (gives us both reproducibility and performance).
  - steeleduncan 7y ago
    Its not that Python packaging doesn't work, or that it is impossible to automate, but whatever you do it requires nontrivial time and effort to get right. The point is that the static binary created by go is a single file that you copy into place and run. It is a lot simpler.

eeZah7Ux 7y ago

This is becoming a parody of software engineering. People are now irrationally scared of using dynamic libraries, OS packages and even directories, like virtualenvs. Instead, a simple solution is replaced with containers, or by rewriting tons of code in the new hyped language. Are we trying to create job security through unnecessary complexity?

grumpydba 7y ago
> Are we trying to create job security through unnecessary complexity? As a python/go dev, I can assure you that go is not much more complex. And as a server admin, it's much easier to deploy. It does have drawbacks when compared to python, but it can often be the optimal solution.
- giancarlostoro 7y ago
  Also a Python dev. I do use VirtualEnv but the other thing is a huge performance boost for small performance intensive projects.
folkrav 7y ago
Isolation is merely one utility of containers.
weberc2 7y ago
This is the weirdest straw man I've seen in a while. Python, not Go, benefits most from containerization. Installing "Dynamic libraries, OS packages, and even directories like virtualenvs" on target machines is far more complicated than sending a single file. I say all this as the DevOps guy in a Python shop.

theshrike79 7y ago

Installing a full virtualenv with all related libraries just to run one script is kind of ridiculous. The server might have the wrong Python version available (2.x vs 3.x, multiple evolutions of 3.x with big features added in each point release). Et cetera, et cetera. Or you could just do it with bash or a static Go binary and be done with it. Portable, works pretty much everywhere.

mtberatwork 7y ago
> The server might have the wrong Python version available That's the point of using virtual environments, so that you can run the Python version and libraries that you need. Also, as of 3.3, Python ships with venv which means you don't need to separately install virtualenv anymore. It's all very portable.
- tseabra 7y ago
  You'd need to install the right Python version though, and even with something like pyenv you might need to install system packages. It really isn't as portable as one might wish.
  - penagwin 7y ago
    This is my exact situation right now. Our website is made in Django, and we use Pyenv to manage our python versions. We'll likely be going to route of a docker image/ pyenv install script. It takes trial/error to figure out some of the packages you need if they aren't installed already, a single binary would be far easier for sure.
- oblio 7y ago
  Portable means something else. Portable would mean that I could ship the virtualenv. Python missed the forest for the trees.
- theshrike79 7y ago
  I still need to have python installed on the machine and download all of the libraries needed. Not all operating systems carry Python >3.3 by default, that would mean installing backports or unofficial repositories on production machines. Or you can use a static binary that just works.

reacharavindh 7y ago

So a virtualenv for every script I want to run? each of that downloading a full Python interpreter and whatever modules that Python script uses? How is this any better than a statically compiled binary? Other than useless additional work and bloat on the servers?

skocznymroczny 7y ago

virtualenv still requires internet access. You'd have to create a venv on destination machine and pip install your packages in. You can't scp a local venv onto destination machine and have it work.

twic 7y ago
I am an utter noob at Python packaging, but i would like to learn more, so excuse the basic question, but: why doesn't it work? And is there anything in the ecosystem which is like that, but does work? I had heard that the Python packaging and deployment story had got a lot better in recent years, but this sounds like it still falls far short of table stakes.
- weberc2 7y ago
  I'm not sure why the Python community can't get it sorted out. We've been using Pipenv because it's one of a few tools that supports lockfiles/reproducible builds, and at the time we chose it, the Python packaging authority was advertising it as the official solution for Python packaging; however, after we were already invested in it, they backpedaled becaused the community realized it was very buggy and super slow (as in "it takes literally half an hour to add or remove or update any dependency"). We're finally getting around to migrating away, and we've settled on Twitter's github.com/pantsbuild/pants which is like Google's Bazel except that it's jankier in every way _except_ that Pants supports Python while Bazel doesn't (Bazel advertises Python support, but it doesn't work as the many Python 3 issues in their issue tracker can attest). The nicest thing about Pants is that it builds pex files (github.com/pantsbuild/pex) which are executable zip files that ship all of your dependencies except the Python interpreter and shared objects. I'm still not very satisfied with this solution, and it's still far, far worse than Go's dependency management and packaging model, but it's a dramatic improvement over Pipenv, virtualenv, etc (gives us both reproducibility and performance).
- steeleduncan 7y ago
  Its not that Python packaging doesn't work, or that it is impossible to automate, but whatever you do it requires nontrivial time and effort to get right. The point is that the static binary created by go is a single file that you copy into place and run. It is a lot simpler.