Docker as an Integrated Development Environment (2019) (opens in new tab)

I’ve been working with Nix for years and I still find it to be disappointing. I don’t like Docker and I really love the Nix concept, but the execution seems poor. As an example, I spent half of a Saturday unsuccessfully working with people on the Nix Discord to get VS Code configured with some Rust plugins on MacOS. Similarly, if you need to write your own package, it might be easy or it might be a bottomless rabbit hole tar pit in which you have to package the entire dependency tree including a bunch of obscure C libraries with no build docs. More often than not it seems to be the latter. Further still, nixpkgs is horribly documented and dynamically typed and poorly organized, so every time you’re looking at a definition for a certain package and want to know what “shape” its dependencies have, you have to grep around for another package that uses it, then try to work out what that package is passing in as the dependency; however, if the dependency object is returned from another function defined in some other file you’ll just have to rinse and repeat until you come across the original definition. This is well below the bar for “professional work”. Problems like these arise every single time I try to work with Nix, and it becomes an enormous time sink. Docker is pretty shit, but there’s a pretty clear upper bound to the time I’ll spend struggling with it. Not so with Nix.

I'm a major user of both and I can definitely say that Dockers basics are easier to learn and teach than Nixs basics. Maybe it has to do with the simple nature of the Dockerfile with just lines of commands, compared to Nix where you first need to learn the Nix language, then the idioms, then the package manager and now you can understand the OS. There is a couple of layers before things start making sense. While a Dockerfile is almost like a line-by-line shellscript.

At least that's my experience. Although I do prefer Nix over Docker any day, I'd definitely say the learning curve is steeper with Nix, but it's so worth it long-term.

>"Which has more users" would not enter the top ten reasons I'd choose between tools like this.

Size of the community, especially if its quality, means you just increased your surface area at getting help for issues you encounter. Which is a very non-trivial concern in a work environment.

> "Which has more users" would not enter the top ten reasons I'd choose between tools like this.

Why not? A big community means that you don't have to solve problems on your own, because someone else has probably solved the same problem before you.

If anything, it should be the <<first>> factor when making these decisions.

> I can't imagine anyone using both and thinking Nix is more complicated that Docker. And it's not close.

Well for starter Nix has a wider syntax because it covers much more than Docker + docker-compose. Which it's perfectly fine because they are two different tools that intersects in few use cases.

Syntax to install a few packages:

environment.systemPackages = with pkgs; [ wget vim nano zsh file ];

Including trailing semicolon. Dockerfile on alpine:

RUN apk add vim nano zsh file

I mean, maybe I'm too used to the latter but I really struggle to find the former simpler.

It means the ecosystem for Docker is more robust than for a Nix, which is patently true (see my comment here: https://news.ycombinator.com/item?id=26689378). I want to like Nix (and indeed I use it for some things), but it’s wildly immature, and maturity is a fine reason to choose one tool over another.

Also “imagine thinking...” is just vapid snark. If you must snark, at least make it substantial.

I'm really impressed with it and am ONLY seeking clarity. I'll be extremely happy if I can use it standalone. Copyright, licensing are all I'm looking at.

e.g. Something like AGPL is considered copyleft and not compatible with 'open source' ethos. Still 'free' but the additional non-compete cloud service clause is both a sensible move, but something I'd just like to understand.

Your statement of 'what's wrong with people' is what is getting me. Borderline defensive. I'm definitely not knocking the product, quite the reverse. Its so good I want to embrace it wholeheartedly.

I have no problem paying for things, contributing voluntarily to a great product.

Its good to see that various organisations are committed to funding the infrastructure costs etc. (which negates my comment about storage servers).

As to monetisation,kind of irrelevant but was referring to paid services at the bottom of https://nixos.wiki/wiki/Nix_Ecosystem

Issue 34 is now closed. My thanks to the patience of people there who have clarified and improved the visibility of licensing.

I am suggesting - vim + plugins or emacs + libraries that use those tools. All integrated as you say.

Your IDE also uses gdb or similar for debugging, common compilers like llvm for compilation / code indexing, common analyzers.

You will have references, definitions, code search, debug, completion, etc all within the editor (in my case emacs)

It all works great and much faster then out-of-the-box IDEs, works within terminal too... no x11 needed.

That still requires some fiddling initially to get it working but once you have your setup its a matter of just pushing it to docker.

Now... the drawback is the time spent to get it, but what i'm saying is don't be dismissive, try and imagine what's possible with old tools.

New tools are also nice in that they avoid that setup work, you can push these too in the docker container and use them the same way.

Where do you find Alpine-compatible wheels? Many ones uploaded to PyPI aren't, because e.g. both GitHub actions [0] and Azure pipelines [1] don't have Alpine images. Is it reasonable to expect maintainers of small, open-source libraries to write and maintain their own Alpine runners?

I guess if you know your company's workflow depends on Alpine, you can build and cache them yourself. But the wider community doesn't benefit from that.

[0] https://docs.github.com/en/actions/using-github-hosted-runne...

[1] https://docs.microsoft.com/en-us/azure/devops/pipelines/agen...

Exactly zero packages upload Alpine-compatible wheels to PyPI.

The manylinux specification assumes glibc, so there is no valid distribution format which would allow the publication of non-glibc wheels.

However there is an in-progress PEP to support it: https://www.python.org/dev/peps/pep-0656/

Niv looks interesting, I’ll have to check it out.

Trawling through git commits, hosting my own binary cache, these are all awful stories. Package versions are the normal pattern, and this lack of support for them in Nix has turned me off the two times I’ve explored using it. I kinda get why they aren’t supported, but it is a huge dissonance from the rest of the software world.