4 ms·

Thanks for your interest, it really confirms the interest I've received from the community in general. 1. I'm leading some Platform Engineering projects at my

Thanks for your interest, it really confirms the interest I've received from the community in general. 1. I'm leading some Platform Engineering projects at my company and one is focused on Developer Experience. We have a wide variety of configurations on the engineer's laptops and the development environments are not normalized. That causes a lot of noise and pain, as one knows. Nix is, or seems to be, an opportunity to take back control on how engineers run the applications locally. 2. I'd say it has many factors. The official documentation and guides are not yet suitable for a zero-knowledge newcomer. As an example, since channels are still recommended in the docs, the command to add the default channel is not in the "Install" page. Things go from `curl <(...) | bash` to `nix-shell`, and it fails (on a M2 Mac) unless I navigate somewhere else on the docs to find that I should add the default channel first. Second point is about the terminology. Derivation, Flakes... are quite arcane terms. At least to the layman (me). Third, community blogs etc are covering outdated versions, some rely on flakes, others not, it's understandle but also understandably disorienting, especially when you're after some guidance that the official docs could not provide. Fourth, the API. `nix-shell` is not a shortcut for `nix shell`. Wait what? --- When I'm saying I'll come back in 2 years, I mean that it is clear that the situation is changing rapidly and dust needs to settle. Maybe the direction is not clear yet, and that would be fine. My one and only advice would be to only ship a feature that is properly documented. Reading something like "We recommend to use flakes, they're the future, but the APIs are in flux, but if you're wary and want stability, here are our stable APIs" would have saved me a ton of time.

jen20 4y ago
> take back control on how engineers run the applications locally. How to piss off engineers in one statement. Developer machines are not something for you to “have control” over.
- citruscomputing 4y ago
  You're right -- but it's even worse DX to have to check a ton of different files, parse the outdated english documentation, guess, ask people, and hope that deps were frozen. Especially for old, mostly abandoned projects. I've started using direnv to switch node versions for projects, based on already-existing CI configuration files, and it's fantastic. Having a full, working, stable development environment that can be shared among the team (amd future teams doing software archaeology when something breaks!) is my holy grail. I'm really excited about the future of nix. But you're right that at the end of the day, devs should retain control. I think having clear, machine readable instructions for how to set up the environment enables that control. Forcing them to use the blessed config is not necessary. HAVING the config lets you know what you need to set up, your own way. The only place such strict control needs to happen is in CI/CD, which just falls out of having the dev setup done.
- ocimbote 4y ago
  Maybe I phrased poorly, but you didn’t try either. Believe it or not, but the project emerges from the devs themselves, it was not even an idea before they spoke up and we had to make it a project, to support them.
- shakow 4y ago
  It's not about ‶controlling the machines″, it's about running `nix-shell -p our-project` and having the same setup on my OpenSuse than Jack on his Arch, Herman on his mac, Johann on her Debian, and our prod environment on RHEL. That's a force multiplier in dev & prod, not a hindrance.
- rkangel 4y ago
  > Developer machines are not something for you to “have control” over. That's exactly right - you want developers to set there machines up however they want. You also want a controlled enclave inside that, that is automatically set up and works consistently to make engineers lives easier and more consistent. One approach people have taken for this is to use docker - a container with all the tools built in. Run the build commands inside this, problem solved. Using Nix achieves something similar, but with some benefits over the docker approach.

jen20 4y ago

> take back control on how engineers run the applications locally. How to piss off engineers in one statement. Developer machines are not something for you to “have control” over.

citruscomputing 4y ago
You're right -- but it's even worse DX to have to check a ton of different files, parse the outdated english documentation, guess, ask people, and hope that deps were frozen. Especially for old, mostly abandoned projects. I've started using direnv to switch node versions for projects, based on already-existing CI configuration files, and it's fantastic. Having a full, working, stable development environment that can be shared among the team (amd future teams doing software archaeology when something breaks!) is my holy grail. I'm really excited about the future of nix. But you're right that at the end of the day, devs should retain control. I think having clear, machine readable instructions for how to set up the environment enables that control. Forcing them to use the blessed config is not necessary. HAVING the config lets you know what you need to set up, your own way. The only place such strict control needs to happen is in CI/CD, which just falls out of having the dev setup done.
ocimbote 4y ago
Maybe I phrased poorly, but you didn’t try either. Believe it or not, but the project emerges from the devs themselves, it was not even an idea before they spoke up and we had to make it a project, to support them.
shakow 4y ago
It's not about ‶controlling the machines″, it's about running `nix-shell -p our-project` and having the same setup on my OpenSuse than Jack on his Arch, Herman on his mac, Johann on her Debian, and our prod environment on RHEL. That's a force multiplier in dev & prod, not a hindrance.
rkangel 4y ago
> Developer machines are not something for you to “have control” over. That's exactly right - you want developers to set there machines up however they want. You also want a controlled enclave inside that, that is automatically set up and works consistently to make engineers lives easier and more consistent. One approach people have taken for this is to use docker - a container with all the tools built in. Run the build commands inside this, problem solved. Using Nix achieves something similar, but with some benefits over the docker approach.