1. 16
  1. 27

    The naming is a hard problem, and I find these project that inject their own vocabulary pretty hard to understand and use. Homebrew thought it’s cute to name everything after brewing, this one is trying the same with cells/biology.

    1. 6

      I started saying this at work - it’s cool that we can name everything after StarCraft, but I think “ API Endpoint” (Endpoint for short) is the best name for an API endpoint

    2. 7

      more here: https://std.divnix.com/

      looks interesting, the naming for internal bits doesn’t seem super obvious but i’ve been very interested in the “library to make Nix flakes simpler” space lately. (come to think of it, “std” might be a bit overloaded to be an easily searchable name…)

      personally, I have been getting a lot of mileage out of https://flake.parts/. anyone using std?

      1. 3

        I’m a flake parts user too. std does look interesting now that i’ve finally looked into it. Assuming I can learn all the unique terminology, I may try it out.

        std also integrates with a number of other projects i’ve never seen before. microvm for instance looks promising.

        1. 1

          I’ve been using Nix for 8 years but I haven’t adopted flakes. Maybe it’s the terminology of flakes mixed with the terminology of cells, etc. but I’m struggling to understand std.

          I guess I have a fundamental question: why do flakes need these libraries to make them usable? I understand the point is code reuse, but where is the duplication coming from?

          I know that many NixOS modules have duplication, some Nix shells do too (e.g. Haskell projects with haskell-language-server or something) and more code reuse would be awesome, but it seems like the flakes libraries aren’t solving those problems.

        2. 2

          I appreciate the attempt to standardize and simplify things. That said– As a very casual nix user with a poor grasp on terminology already, I found the current docs to be unintelligible.