4 ms·

Do your developers run the same Nix packages that you deploy to production? (that sounds like a energy-level-transition in developer productivity and debugging

by jka 5y ago

Do your developers run the same Nix packages that you deploy to production? (that sounds like a energy-level-transition in developer productivity and debugging capability, if so)

smilliken 5y ago
Yeah, the environment is bit-for-bit identical in dev and prod. Any difference is an opportunity for bugs. OK, there's one concession, there's an env var that indicates if it's a dev and prod environment. We try to use it sparingly. Useful for stuff like not reporting exceptions that originate in a dev environment. Basically, there's a default.nix file in the repo, and you run nix-shell and it builds and launches you into the environment. We don't depend on anything outside of the environment. There's also a dev.nix and a prod.nix, with that single env var different. There's nothing you can't run and test natively, including databases. Oh, it also works on MacOS, but that's a different environment because some dependencies don't make sense on MacOS, so some stuff is missing.
- Gwypaas 5y ago
  How do you manage quick iteration loops?
  - smilliken 5y ago
    We use python. If we were writing in a compiled language, we'd use the same compiler toolchain as everyone else, but with the versions of all of our dependencies exactly the same from nix. We have some c extensions and compile Typescript and deploy those build artifacts. In the case of javascript, our node modules is built by nix, and our own code is built by webpack --watch in development.
- jka 5y ago
  That sounds extremely impressive, thank you. I hope to find some time to try out Nix soon (appending it to the list of technologies to learn...).
- kazinator 5y ago
  Does that mean you turn off security-related randomizations in everything, like address space randomization and hash table randomization?
  - smilliken 5y ago
    No, we have address space randomization and hash table randomization since those happen at runtime. /dev/random works as you'd expect. The immutability is just at build time. So chrome and firefox aren't able to seed a unique ID in the binaries like you might be accustomed to. Funny story, we had a python dependency that would try to update itself when you imported it. I noticed because it would raise an exception when it was on a read only mount.

by jka 5y ago

Do your developers run the same Nix packages that you deploy to production? (that sounds like a energy-level-transition in developer productivity and debugging capability, if so)

smilliken 5y ago

Yeah, the environment is bit-for-bit identical in dev and prod. Any difference is an opportunity for bugs. OK, there's one concession, there's an env var that indicates if it's a dev and prod environment. We try to use it sparingly. Useful for stuff like not reporting exceptions that originate in a dev environment. Basically, there's a default.nix file in the repo, and you run nix-shell and it builds and launches you into the environment. We don't depend on anything outside of the environment. There's also a dev.nix and a prod.nix, with that single env var different. There's nothing you can't run and test natively, including databases. Oh, it also works on MacOS, but that's a different environment because some dependencies don't make sense on MacOS, so some stuff is missing.

Gwypaas 5y ago
How do you manage quick iteration loops?
- smilliken 5y ago
  We use python. If we were writing in a compiled language, we'd use the same compiler toolchain as everyone else, but with the versions of all of our dependencies exactly the same from nix. We have some c extensions and compile Typescript and deploy those build artifacts. In the case of javascript, our node modules is built by nix, and our own code is built by webpack --watch in development.
jka 5y ago
That sounds extremely impressive, thank you. I hope to find some time to try out Nix soon (appending it to the list of technologies to learn...).
kazinator 5y ago
Does that mean you turn off security-related randomizations in everything, like address space randomization and hash table randomization?
- smilliken 5y ago
  No, we have address space randomization and hash table randomization since those happen at runtime. /dev/random works as you'd expect. The immutability is just at build time. So chrome and firefox aren't able to seed a unique ID in the binaries like you might be accustomed to. Funny story, we had a python dependency that would try to update itself when you imported it. I noticed because it would raise an exception when it was on a read only mount.