From this description it seems to solve the same issue.

I could imagine something like environment variables, but on the other hand that's something I've learned not to keep in version control, and putting it in docker would be exactly that, no?

It's not, it solves a different issue. If you only have Python as dependency, requirements.txt are fine (well, user needs to install correct version of Python, pip and virtualenv / pipenv, but that's doable). But as soon as your app is actually composed of nginx / apache, python, some background process in Rust, bash scripts for cron jobs,... then you have a problem with app delivery, which Docker solves nicely. Just package eveything in a Dockerfile and distribute the image. Bonus point: you can now test it locally, with the same installation.

I jumped on Docker wagon very early for this exact reason. I don't care about hype, but it does solve these kinds of problems.

> Why is docker better than virtualenv with a requirements.txt file

One of issues that `docker-compose build` solves better is that venv is superconfusing to your non-python users. I've had people:

- skip it and do `python setup.py install` instead - skip it and install requirements globally `pip install -r requirements.txt` because thats how it worked for them last time they used python - version control their `venv` directory - backup and upload their `venv` directory on new server when moving

Now they just do `./appctl setup` that asks them for few things, writes `setup.env` file for docker-compose, and then runs `docker-compose build`

But this is only beginning. Thanks to `docker-compose` that `build` step also installs:

- PostgreSQL database - Redis for caching and message queue - UWSGI - Celery - Nginx proxy

You can't put postgres, memcached, imagemagick in requirement.txt, can you?

https://nickjanetakis.com/blog/setting-up-a-python-developme...

The TL;DR is a typical web app is often a lot more than just running Python, and there's a huge amount of value in being able to run the same code across different operating systems without any installation changes.

Hm, I'm pretty sure I can take any Go project out there and build it in a matter of minutes on my current OS (depending on the build time of course). Just a matter of setting the environment on the right compiler binary and retrieving dependencies (which just came better 2 weeks ago with 1.11's modules).

I'm pretty sure too I'll very quickly run into dependencies hell by picking randoms ruby/python programs. Just take a look at that SO question: https://stackoverflow.com/questions/2812471/is-there-a-pytho....

Interpreted languages have their uses, of course, but there's a clear difference in both ease of deployment and development between the realms of interpreted languages (Ruby/Python/PHP/etc.), VM/IL/JIT based languages (JVM/.NET/etc.) and 'plain old' compiler based languages (C/C++/Rust/Go/etc.).

> In fact build awkwardness is orthogonal to static vs dynamic typing.

I said "interpreted languages' ecosystems", not "dynamically typed languages". I think you're mixing concepts here (or just maybe you're adding info not directly related to my comment).

Which is exactly how it works in Python.

I'm pretty sure too I'll very quickly run into dependencies hell by picking randoms ruby/python programs. Just take a look at that SO question:

That SO question is about a tool for "setting the environment on the right compiler binary and retrieving dependencies". But you can also do it manually just fine; that's how I usually did it, in fact. Just retrieve the dependencies to a directory and call Python with PYTHONPATH set to it.

Pyenv is essentially the same as Go's new modules tool, it's just not called through the same binary as the interpreter/compiler.

Interpreted languages have their uses, of course, but there's a clear difference in both ease of deployment and development between the realms of interpreted languages (Ruby/Python/PHP/etc.), VM/IL/JIT based languages (JVM/.NET/etc.) and 'plain old' compiler based languages (C/C++/Rust/Go/etc.).

Yes; with Python, you can both run directly from source without wasting time compiling after each change, or you can produce a standalone binary (dependent only on libc) for distribution, using a tool like PyInstaller. Plain old compiled based languages are much more limited.

As I said, interpreted languages have their uses, of course. My initial point was about delivery to end users.

What makes us successful as software engineers, in the end (and IMHO), is the efficiency level at which we reach our goals. To my eyes, when deliverability is the goal, then a language where native (cross)compilation is first class citizen is the most efficient path. But don't get me wrong, Python is really great and still a good choice for that scenario (I'm thinking of dropbox, for ex).

You said at first "Dev builds are just as annoying with Golang as Ruby or Python" and now you're saying "I can build any python [...] I can't do that with [...] Ruby"?

It seems like you think there's a "build process" with Go because you're accustomed to python/pyenv (or whatever is your env manager of choice), in which cas you need to known that there's no such thing with Go.

The two following course of actions are the same: - "apt-get docker; docker pull {project-url}; docker start {project-url}" - "apt-get golang; git pull {project-url}; go run .go" (the last Go 1.11 will take care of dependencies at build time)

You can't as easily do "apt-get python; git pull {url}; python .py", unless the program is really simple, because there's such questions as "python2 or 3?" or "pyenv, virtualenv or anaconda?", obligatory XKCD here: https://xkcd.com/1987.

But it's totally ok not to bother learning the compilation command of a given project's language and rely on Docker, really I'm ok with that, doing it myself from time to time. My initial point was on app delivery to final users.

"apt install python3 python3-pipenv; git pull {url}; pipenv sync; python3 .py"

pipenv sync sets up a virtual env and pulls all the dependencies.

With docker, you can just ignore all that. As long as there is a single person capable of updating the dependencies on a single machine with docker, it'll work the same everywhere, always.

Every member of team will need to run same version of Fedora directly or in Vagrant or in (ta-da) docker container.

From my experience, it turned out that for small Dockerfile's, RPM packages are unnecessary burden, so usually I just start with just docker. But later, when Dockerfile growths, it much harder to track dependencies and installation instructions, when they are interleaved, so it much easier to return to individually packaged programs and replace almost whole content of Dockerfile with single "dnf install meta-package" command.