Threads for lucilleh
-
DevOps is a cultural / social movement to bring devs and ops closer together through embracing configuration as code, automation, source control, fast feedback loops etc….
“Zero devops” makes it sounds like project is claiming those things don’t matter.
-
-
I’d bring it back to the problem you’re solving.
e.g.
- Are you removing the need to have any Kubernetes knowledge?
= “Kubernetes Deployments - Without Any Kubernetes Knowledge”
- Are you removing the need to have template scaffolding such as helm in order to deploy applications to a Kubernetes cluster?
= “Templated Kubernetes Deployments without messy helm charts”
- Are you bundling multiple usually discreet services / tools together?
= “All in one kubernetes deployments without the needs for custom CI scripts, docker build wrappers, helm chart templates or deploy manifests”
Something like that I think.
-
-
Replacing
flake.nix#shellsor the legacyshell.nixwith a JSON file doesn’t simplify things—it hides them it another layer. This would be a step back since you lose a lot of flexibility in the Nix language, but also that you can have more than thedefaultshell. Besides that they dared use the word “magical” when Nix isn’t magic, also hiding under this veneer is that Nix is best served as the build tool so the entire build system is repoducible/predictable. The fact that NGINX “no longer work[s] in a standard way” is the feature because it isn’t mutable.We’re huge fans of Nix, and Nix flakes are really powerful tools for creating reproducible builds. We first built Devbox as an internal tool to make it easy to create Nix-based dev environments, while providing configuration options that are more familiar to developers who have previously used packages like NGINX. We’re hoping that a more approachable interface for creating dev environments can help drive adoption of Nix overall.
I think this is sending the wrong message. There is a lot of people searching for “how do I get my Nix shell into Docker for deployment” because they missed the point that the dev shell isn’t the killer feature of Nix–replacing Docker, and your dev shell, and your build tool is (or building your container with Nix because of deployment constraints dictating containers). You want the build to be top-to-bottom immutable. Creating state at any level of that ruins the reproducibility part–including a mutable shell. I get it: Nix is a learning cliff and the dev shell seems like a gentle introduction, but until you go further, you’re missing out on the biggest benefits. And the thing is that setting up the dev shell is the easy part, and getting familiar with Nix the language with a
flake.nixorshell.nixis the only way you’ll start to get there (that said, Guile Scheme+Guix is also a worthy alternative to Nix doing roughly the same thing). So is the idea that developers can’t be asked to learn the tools they are using so it’s behind a JSON layer?Mutability is not necessarily bad if it is declarative rather than imperative. You can still reproduce the entire shell top to bottom with a declarative mutable local store that is ephemeral, which is created at installation time. In this case the reproducibility is not compromised at all since the configuration is still declarative, but it allows a more standard way of using packages that expect mutability. The bad part of mutability is when it is used in an imperative way stored in a permanent location.
On dev shell isn’t a killer feature of Nix - why not? I think it actually can be. Well, I certainly hope so!