4 ms·

PNPM (a package manager for JavaScript/NPM ecosystem) does this with much better usability: > let's you control your dependencies in a way no other tool even a

by jitl 3y ago

PNPM (a package manager for JavaScript/NPM ecosystem) does this with much better usability: > let's you control your dependencies in a way no other tool even attempts. I can pin and patch any combination of dependencies, even conflicting ones in single environment It does so with much lower user facing complexity than Nix. I like flakes because they’re trying to follow a similar model, but still quite hard to teach newcomers: - The CLI should literally have the same verbs as PNPM, but needs a bunch of complicated flags to do the same actions. - The nix expression language is intimidating and has kinda bad tooling out of the box. I would love to use Starlark/Python/Typescript instead. Even Guix’s scheme language is more appealing to me, although Guix is too niche and GNU focused to be practical. - Nix package files evaluate down to configuration for the Nix package manager, but I haven’t ever seen a good explanation for the basic essentials underneath all the abstraction. Every guide I’ve learned from and all the package defs I’ve read seem to cargo cult many layers of mysterious config composing config. Without easy to learn essentials it’s difficult to grok the system as a whole. I would love to adopt Nix for developer tooling for Notion’s engineers, but today it’s about infinity times easier to work around the limitations mentioned of Docker+Ubuntu+NPM than to work around the limitations of Nix.

jkarni 3y ago
Garn [0] is most of that: simpler CLI, and Typescript for configuration, though lying on top of Nix. (Disclaimer: I work on garn) [0] https://github.com/garnix-io/garn https://github.com/garnix-io/garn
- jitl 3y ago
  I looked at the docs, and it seems promising but I’d like to do something like: `garn add --dev git@2.3` and have git added at the given version as a dev tool. With config-as-code, is it possible?
Cu3PO42 3y ago
I don't think you can ever get Nix as simple as PNPM, simply because native libraries are sometimes annoying, need to be configured at build time to a greater degree and because the problem space it attacks is so much larger than PNPM, which only deals with the JS/Node.js ecosystem. However, I do think that there exist reasonable levels of abstraction that sacrifice some expressive power for simplicity and such systems could maybe expose a PNPM-like CLI. One example that comes to mind is devenv.nix [1]. While it doesn't yet have a CLI, its configuration file is YAML and relatively simple. I think there's more to be done in this space and I hope for tools that are easier to grasp in the future. > Nix package files evaluate down to configuration for the Nix package manager, but I haven’t ever seen a good explanation for the basic essentials underneath all the abstraction. Every guide I’ve learned from and all the package defs I’ve read seem to cargo cult many layers of mysterious config composing config. Without easy to learn essentials it’s difficult to grok the system as a whole. To me it sounds like the essential that you're referring to is the 'derivation' primitive, which is almost always hidden behind the mkDerivation abstraction from nixpkgs. This [2] blog post is an exploration of what exactly that means. I'd also love for the documentation situation to be much better, in particular in terms of official, curated resources. But I'm not convinced that you actually need to know the difference between derivation and mkDerivation to make effective use of Nix, because in practice you would always use the latter. That said, mkDerivation and the whole of nixpkgs is essentially a huge DSL (I believe this is what you meant when you said 'config composing config') that you do need to know and is woefully underdocumented. > I would love to adopt Nix for developer tooling for Notion’s engineers, but today it’s about infinity times easier to work around the limitations mentioned of Docker+Ubuntu+NPM than to work around the limitations of Nix. One approach I have taken to is to specify the environment in Nix, but then generate Docker devcontainers from it, so most people don't come into contact with Nix if they don't want to. [1] https://devenv.sh https://devenv.sh [2] https://ianthehenry.com/posts/how-to-learn-nix/derivations/ https://ianthehenry.com/posts/how-to-learn-nix/derivations/

by jitl 3y ago

jkarni 3y ago

Garn [0] is most of that: simpler CLI, and Typescript for configuration, though lying on top of Nix. (Disclaimer: I work on garn) [0] https://github.com/garnix-io/garn https://github.com/garnix-io/garn

jitl 3y ago
I looked at the docs, and it seems promising but I’d like to do something like: `garn add --dev git@2.3` and have git added at the given version as a dev tool. With config-as-code, is it possible?

Cu3PO42 3y ago

I don't think you can ever get Nix as simple as PNPM, simply because native libraries are sometimes annoying, need to be configured at build time to a greater degree and because the problem space it attacks is so much larger than PNPM, which only deals with the JS/Node.js ecosystem. However, I do think that there exist reasonable levels of abstraction that sacrifice some expressive power for simplicity and such systems could maybe expose a PNPM-like CLI. One example that comes to mind is devenv.nix [1]. While it doesn't yet have a CLI, its configuration file is YAML and relatively simple. I think there's more to be done in this space and I hope for tools that are easier to grasp in the future. > Nix package files evaluate down to configuration for the Nix package manager, but I haven’t ever seen a good explanation for the basic essentials underneath all the abstraction. Every guide I’ve learned from and all the package defs I’ve read seem to cargo cult many layers of mysterious config composing config. Without easy to learn essentials it’s difficult to grok the system as a whole. To me it sounds like the essential that you're referring to is the 'derivation' primitive, which is almost always hidden behind the mkDerivation abstraction from nixpkgs. This [2] blog post is an exploration of what exactly that means. I'd also love for the documentation situation to be much better, in particular in terms of official, curated resources. But I'm not convinced that you actually need to know the difference between derivation and mkDerivation to make effective use of Nix, because in practice you would always use the latter. That said, mkDerivation and the whole of nixpkgs is essentially a huge DSL (I believe this is what you meant when you said 'config composing config') that you do need to know and is woefully underdocumented. > I would love to adopt Nix for developer tooling for Notion’s engineers, but today it’s about infinity times easier to work around the limitations mentioned of Docker+Ubuntu+NPM than to work around the limitations of Nix. One approach I have taken to is to specify the environment in Nix, but then generate Docker devcontainers from it, so most people don't come into contact with Nix if they don't want to. [1] https://devenv.sh https://devenv.sh [2] https://ianthehenry.com/posts/how-to-learn-nix/derivations/ https://ianthehenry.com/posts/how-to-learn-nix/derivations/