Live data from Hacker News

Haskell developer experience in NixOS

kuznero.com

11–20 of 20 posts

Re: Haskell developer experience in NixOS

#11

I'm not a Haskell developer nor Nix user, but I find Docker is surprisingly convenient, if only for its immutable layers file & build system: as I test different packages, I only pay for what's changed or removed, not the full setup. For example, for a C library, you might start with RUN apt install -y build-essential RUN apt install -y libopenssl-dev RUN cd src && ./configure but if libopenssl-dev is the wrong packa…

> but it's probably more complicated and harder the reason about

Absolutely not. It's made far easier to reason about through the fact that all of its features are exposed through a pure-functional language, giving the reader the ability to reason about each expression inside each level of brackets individually. It's extremely freeing reasoning about code once you realize you can rule out side effects.

Re: Haskell developer experience in NixOS

#12
post #8

I'm not a Haskell developer nor Nix user, but I find Docker is surprisingly convenient, if only for its immutable layers file & build system: as I test different packages, I only pay for what's changed or removed, not the full setup. For example, for a C library, you might start with RUN apt install -y build-essential RUN apt install -y libopenssl-dev RUN cd src && ./configure but if libopenssl-dev is the wrong packa…

Docker is a nice runtime, but you cannot reproduce the build of a docker container. What if you want to make a small change to the image? You need to rebuild it, but if it's years later, the versions of packages in the ubuntu repository may have changed and a lot of other things (if you're not careful, tarballs downloaded during the building of the image may have disappeared/changed/...). While you can try to avoid t…

Could reproducible Docker builds be achieved through adding Nix, then? Maybe that really ought to be the best practice for people doing this on a large scale.

Re: Haskell developer experience in NixOS

#13
post #8

I'm not a Haskell developer nor Nix user, but I find Docker is surprisingly convenient, if only for its immutable layers file & build system: as I test different packages, I only pay for what's changed or removed, not the full setup. For example, for a C library, you might start with RUN apt install -y build-essential RUN apt install -y libopenssl-dev RUN cd src && ./configure but if libopenssl-dev is the wrong packa…

Docker is a nice runtime, but you cannot reproduce the build of a docker container. What if you want to make a small change to the image? You need to rebuild it, but if it's years later, the versions of packages in the ubuntu repository may have changed and a lot of other things (if you're not careful, tarballs downloaded during the building of the image may have disappeared/changed/...). While you can try to avoid t…

> Docker is a nice runtime, but you cannot reproduce the build of a docker container

This is a common misconception but there's plenty of info out there if you want to find out how to do it. https://duckduckgo.com/?q=reproducible+builds+in+docker&atb=...

In essence, you can make reproducible builds in docker by controlling the build environment and then specifying particlar versions when installing dependencies. It's a bit more work but it's eminently doable.

You control the build environment by building your reproducible docker containers within an environment (eg a reproducible docker container) that is itself reproducible (ie with specified versions of everything). This seems like a bootstrapping problem, but actually it works.

So: 1. Make a "Build container" with a specified base image version and specified versions of the transitive deps of everything it needs to build your thing 2. Use this container to build your actual container, specifiying a version of the base image and all dependencies.

Pretty sure you don't need more than these two layers of the onion to make bitwise-identical builds as long as your package build recipe is itself reproducible (eg the toolchain supports it and you don't do anything like embedding timestamps etc in the binaries).

Package managers provide mechanisms to get the version list in force so generally the way to do this is to start with your preferred base image, install all the packages you want/need, use the package manager to give you the version list, then change the Dockerfile to install specifically those versions.

Re: Haskell developer experience in NixOS

#14
post #12
post #8

Earlier quoted context omitted.

Docker is a nice runtime, but you cannot reproduce the build of a docker container. What if you want to make a small change to the image? You need to rebuild it, but if it's years later, the versions of packages in the ubuntu repository may have changed and a lot of other things (if you're not careful, tarballs downloaded during the building of the image may have disappeared/changed/...). While you can try to avoid t…

Could reproducible Docker builds be achieved through adding Nix, then? Maybe that really ought to be the best practice for people doing this on a large scale.

Absolutely! From my point-of-view, Nix is complementary to Docker. Nix is a deterministic replacement for the apt-get commands used in the parent post.

Re: Haskell developer experience in NixOS

#15
post #8

Earlier quoted context omitted.

Docker is a nice runtime, but you cannot reproduce the build of a docker container. What if you want to make a small change to the image? You need to rebuild it, but if it's years later, the versions of packages in the ubuntu repository may have changed and a lot of other things (if you're not careful, tarballs downloaded during the building of the image may have disappeared/changed/...). While you can try to avoid t…

> Docker is a nice runtime, but you cannot reproduce the build of a docker container This is a common misconception but there's plenty of info out there if you want to find out how to do it. https://duckduckgo.com/?q=reproducible+builds+in+docker&atb=... In essence, you can make reproducible builds in docker by controlling the build environment and then specifying particlar versions when installing dependencies. It's…

> In essence, you can make reproducible builds in docker by controlling the build environment and then specifying particular versions when installing dependencies.

Nix would be an excellent way to achieve this.

Re: Haskell developer experience in NixOS

#16
post #8

I'm not a Haskell developer nor Nix user, but I find Docker is surprisingly convenient, if only for its immutable layers file & build system: as I test different packages, I only pay for what's changed or removed, not the full setup. For example, for a C library, you might start with RUN apt install -y build-essential RUN apt install -y libopenssl-dev RUN cd src && ./configure but if libopenssl-dev is the wrong packa…

Docker is a nice runtime, but you cannot reproduce the build of a docker container. What if you want to make a small change to the image? You need to rebuild it, but if it's years later, the versions of packages in the ubuntu repository may have changed and a lot of other things (if you're not careful, tarballs downloaded during the building of the image may have disappeared/changed/...). While you can try to avoid t…

> Just pin your nixpkgs version, and you can almost guarrante that you'll get the exact same build years later and you can still change parts of it if you need to.

In theory. In practice, anything that doesn't hit the NixOS cache server will likely have been removed; it doesn't cache the build inputs, and links break all the time. On smaller timescales it's brilliant, though.

Re: Haskell developer experience in NixOS

#17
post #15

Earlier quoted context omitted.

> Docker is a nice runtime, but you cannot reproduce the build of a docker container This is a common misconception but there's plenty of info out there if you want to find out how to do it. https://duckduckgo.com/?q=reproducible+builds+in+docker&atb=... In essence, you can make reproducible builds in docker by controlling the build environment and then specifying particlar versions when installing dependencies. It's…

> In essence, you can make reproducible builds in docker by controlling the build environment and then specifying particular versions when installing dependencies. Nix would be an excellent way to achieve this.

Nixpkgs has a function for creating Docker images as derivations, in fact.

Re: Haskell developer experience in NixOS

#18
post #12
post #8

Earlier quoted context omitted.

Docker is a nice runtime, but you cannot reproduce the build of a docker container. What if you want to make a small change to the image? You need to rebuild it, but if it's years later, the versions of packages in the ubuntu repository may have changed and a lot of other things (if you're not careful, tarballs downloaded during the building of the image may have disappeared/changed/...). While you can try to avoid t…

Could reproducible Docker builds be achieved through adding Nix, then? Maybe that really ought to be the best practice for people doing this on a large scale.

It already has all the needed infrastructure, in fact. See for example http://lethalman.blogspot.ie/2016/04/cheap-docker-images-wit...

Re: Haskell developer experience in NixOS

#19
I feel the need to plug my take on NixOS, but based on ArchLinux

https://github.com/shawndellysse/effuvv

NixOS is awesome, but it requires you to relearn all your sysadmin techniques; this is great in the long run but not so great in the short run. effuvv tries to be a solid middle-ground between traditional linux and functional system management

Post reply on HN