Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Docker as an Integrated Development Environment (2019)

medium.com

Post reply on HN
Print view View original

81–90 of 93 posts

Re: Docker as an Integrated Development Environment (2019)

#81

Post by mintyc »

capableweb wrote: post #49
mintyc wrote: post #48

Earlier quoted context omitted.

It looks impressive but it isn't clear how much you have to pay for services from them. It isn't free and you aren't in control. Your snapshots and abilities to rollback etc are likely to be dependent on their storage servers. They certainly should monetise, but not making it clear is what I object to. I've raised as an issue for clarification in their community wiki. https://github.com/nix-community/wiki/issues/34

Mmmm, no. Nix is not a SaaS that builds your snapshots that you have to pay for (or that "they need to monotize", what's wrong with people?), it's a whole ecosystem ranging from a full OS (NixOS) down to a package manager (Nix Package Manager) and programming language (just "Nix). Not sure what needs clarification here, it's pretty up-front about it's mission and features already. > Your snapshots and abilities to ro…

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

Re: Docker as an Integrated Development Environment (2019)

#82

Post by mintyc »

mintyc wrote: post #48
amarant wrote: post #32

Personally I'd prefer going with NixOS to achieve the same result. that way you don't even need a docker installation. As a bonus you can actually install the Nix package manager on osx if you're not into Linux (and this way there is no need for virtualization if you're on a Mac) More info: https://nixos.org/

It looks impressive but it isn't clear how much you have to pay for services from them. It isn't free and you aren't in control. Your snapshots and abilities to rollback etc are likely to be dependent on their storage servers. They certainly should monetise, but not making it clear is what I object to. I've raised as an issue for clarification in their community wiki. https://github.com/nix-community/wiki/issues/34

As noted below, my initial wording was unhelpful and misplaced.

The infrastructure costs are covered by sponsors. The 'They should monetise' was a 'they' that I now understand are external organisations rather than nixos themselves.

Re: Docker as an Integrated Development Environment (2019)

#83

Post by guitarbill »

williamjackson wrote: post #67
codethief wrote: post #42

Earlier quoted context omitted.

Case in point: "Using Alpine can make Python Docker builds 50× slower", https://pythonspeed.com/articles/alpine-docker-python/

That article should be titled, “Most Python packages do not upload an Alpine-compatible wheel to PyPI.” If you know where to find Alpine-compatible wheels, or host your own, Alpine has no build-speed penalty.

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...

Re: Docker as an Integrated Development Environment (2019)

#84

Post by darkwater »

bachmeier wrote: post #50
darkwater wrote: post #41

Earlier quoted context omitted.

So you just shifted your dependency from Docker to Nix. It might be more fun and an intetesting learning experience but also it's more complicated (or at least it's not that widely used like Docker is)

> It might be more fun and an intetesting learning experience but also it's more complicated I can't imagine anyone using both and thinking Nix is more complicated that Docker. And it's not close. > at least it's not that widely used like Docker is "Which has more users" would not enter the top ten reasons I'd choose between tools like this.

> 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.

Re: Docker as an Integrated Development Environment (2019)

#85

Post by capableweb »

emptysongglass wrote: post #76
throwaway894345 wrote: post #69

Earlier quoted context omitted.

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…

Can you link the Nix Discord?

As far as I know, the only official chat channels is #nixos (and #nixos-* friends) on Freenode (https://nixos.wiki/wiki/Get_In_Touch). There is an unofficial Discord, but I'd advice you to join the IRC channels instead, fast help and the people contributing to Nix actually hangs around as well.

Re: Docker as an Integrated Development Environment (2019)

#86

Post by emptysongglass »

capableweb wrote: post #85
emptysongglass wrote: post #76

Earlier quoted context omitted.

Can you link the Nix Discord?

As far as I know, the only official chat channels is #nixos (and #nixos-* friends) on Freenode ( https://nixos.wiki/wiki/Get_In_Touch ). There is an unofficial Discord, but I'd advice you to join the IRC channels instead, fast help and the people contributing to Nix actually hangs around as well.

I've actually had terrible success getting help through the official channels: it's why I asked.

Re: Docker as an Integrated Development Environment (2019)

#87

Post by williamjackson »

guitarbill wrote: post #83
williamjackson wrote: post #67

Earlier quoted context omitted.

That article should be titled, “Most Python packages do not upload an Alpine-compatible wheel to PyPI.” If you know where to find Alpine-compatible wheels, or host your own, Alpine has no build-speed penalty.

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 b…

I was not aware of prior work so I maintain Alpine wheels for packages I use personally in a GitHub org.

https://github.com/alpine-wheels/index

Besides my own needs, only one other person has requested additional packages, which I was happy to add. Maintenance is minimal, mostly just approving pull requests created by Dependabot.

Re: Docker as an Integrated Development Environment (2019)

#88

Post by qbasic_forever »

kamac wrote: post #54
qbasic_forever wrote: post #18

Go the next step and run a local kubernetes cluster with kind or k3s (it will take you 30 seconds to have a k8s cluster going). IMHO the kubectl CLI is a lot more logical than docker's CLI. You can create all your local storage volumes ahead of time, create a pod that attaches to it, and then just kubectl exec into the pod vs. writing a long fiddly docker command line string (or crafting a docker-compose.yml). It's e…

Won’t setting up a k8s cluster require writing resource definitions? I imagine you’d need to write a statefulset. How’s that better than writing a docker-compose? I’m not sure how vscode does it, but it allows you to publish ports in real time as well.

Nope you can make a simple pod definition and not worry about a deployment. For a local cluster you'll just have one node and everything is effectively a statefulset. IMHO it's easier to write k8s yaml, there's tons of tooling, clear schemas, etc. You could even script calling the API server directly.

Re: Docker as an Integrated Development Environment (2019)

#89

Post by throwaway894345 »

amarant wrote: post #79
throwaway894345 wrote: post #69

Earlier quoted context omitted.

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…

I agree actually, you describe the issues I've had with nix quite head on. I've not ran into such issues every single time i try it, but I have hit upon a good deal of issues of the kind you describe. Nix is by no means perfect, and if I was smarter I'd try to remake it with a stronger type system, but the basic premise is useful enough on it's own to warrant usage IMO

I’ve thought a lot about a type system for Nix. Typing the mix expression language would improve some things, but since so much of what people do with the Nix expression language is writing scripts that take in files and transform them into other files, you would really want a type system for the derivations which could describe the “shape” of the input and output files. I’m not aware of any such type system, but it would be a really interesting area of research. Would love to know if others have thought about this or not.

Re: Docker as an Integrated Development Environment (2019)

#90

Post by guitarbill »

williamjackson wrote: post #87
guitarbill wrote: post #83

Earlier quoted context omitted.

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 b…

I was not aware of prior work so I maintain Alpine wheels for packages I use personally in a GitHub org. https://github.com/alpine-wheels/index Besides my own needs, only one other person has requested additional packages, which I was happy to add. Maintenance is minimal, mostly just approving pull requests created by Dependabot.

That's pretty slick! Thanks
Post reply on HN