• chaorace@lemmy.sdf.org
    link
    fedilink
    English
    arrow-up
    7
    ·
    10 months ago

    I like flakes a lot, speaking as a type of user which I’ll call a “casual packager”.

    This is to say that I like being a good citizen and sharing my packaging efforts… while also simultaneously feeling totally uninterested in becoming an owner-for-life. Flakes let me share a package without those pesky strings – when the user installs a package using one of my flakes, a personal lockfile gets generated at the latest git commit and that’s that. If the user doesn’t like the version they get, then the power is in their hands to choose a different git ref via their own generated lockfile.

    Obviously this is something of a user footgun, especially for consumers of high-impact or security-critical applications, but most of those things are already important enough to get packaged. When it comes to niche, infrequently updated stuff, this approach works super well and helps to draw many reluctant packagers like myself out into the open.

  • parens@programming.dev
    link
    fedilink
    English
    arrow-up
    1
    ·
    10 months ago

    Flakes are optional

    I think the bigger point is that they are experimental. Who wants to go into production with experimental stuff? Unfortunately, if my employer were to read a suggestion of using experimental stuff in production, it would be immediately rejected.
    nix itself, however, has been getting some people interested at work and if things go well, might be integrated into production solutions we sell to customers.

    • null@slrpnk.net
      link
      fedilink
      English
      arrow-up
      3
      ·
      10 months ago

      They really should be moved out of that category soon. They’ve been so fully embraced and used by the community that they’re effectively standard now.

      • parens@programming.dev
        link
        fedilink
        English
        arrow-up
        3
        arrow-down
        1
        ·
        10 months ago

        The article clearly states otherwise

        Flakes also are a symptom or cause of much intra-community strife between “pro-flakes” and “anti-flakes” factions

        • null@slrpnk.net
          link
          fedilink
          English
          arrow-up
          2
          ·
          edit-2
          10 months ago

          Oh, that’s easy – that’s utter bullshit. Article is generous, this is a blog post.

            • null@slrpnk.net
              link
              fedilink
              English
              arrow-up
              2
              arrow-down
              1
              ·
              10 months ago

              Because I’m pretty active in the Nix community and have never seen a single anti-flakes comment anywhere. Plenty of people advocating for flakes, and those who don’t use or understand flakes. But never anyone who actively dislikes them.

              • parens@programming.dev
                link
                fedilink
                English
                arrow-up
                1
                arrow-down
                2
                ·
                10 months ago

                OK, I see where you’re coming from. You’re interpreting “anti” as “dislike”. Have you considered interpreting it as those who don’t use and don’t want to use flakes?

                Just because there is disagreement, doesn’t mean that it has to be tied to negative emotions like hate or dislike.

                • null@slrpnk.net
                  link
                  fedilink
                  English
                  arrow-up
                  2
                  arrow-down
                  1
                  ·
                  10 months ago

                  Well no, because that’s not what “anti” means.

                  And one can absolutely use NixOS without using flakes, whether they’re marked experimental or not. They’re simply a way to make inputs declarative, rather than the nix-channel method which is imperative.

                  So there’s no “disagreement” here either.

    • Corbin@programming.dev
      link
      fedilink
      English
      arrow-up
      2
      ·
      10 months ago

      It must be nice to have never productionized a prototype; meanwhile, in the land of startups, putting experiments into production is standard operating procedure, despite being a bad idea.

      The more important part is that flakes are unstable. The concept is solid and clearly works at scale, but the precise API available to users is not yet finalized or versioned.

      • parens@programming.dev
        link
        fedilink
        English
        arrow-up
        2
        ·
        10 months ago

        It must be nice to have never productionized a prototype; meanwhile, in the land of startups, putting experiments into production is standard operating procedure, despite being a bad idea.

        You’re making assumptions. I worked in startups that did took great care not to beta software or libs. We were in production and changing stuff all the time - multiple times a day, but that was one of the rules. When you work with time-sensitive, always on environments with world-wide customers, bringing down production for multiple hours could mean the end your company in those early stages.
        Maybe I was extra-ordinarily lucky with the startups I was in.

        Just because other startups do it, doesn’t mean that it has to be done.

  • Gooey0210@sh.itjust.works
    link
    fedilink
    English
    arrow-up
    1
    ·
    10 months ago

    I need to read it, and do everything the other way

    It took me months to understand that i don’t need to nix channel update if i’m on flakes

    Or do i need? 😂

  • ericjmorey@programming.dev
    link
    fedilink
    English
    arrow-up
    1
    arrow-down
    1
    ·
    10 months ago

    I think that Nix flakes have some considerable benefits, such as:

    Convenient pinning of evaluation-time dependencies

    Eliminating pointless rebuilds of code by only including tracked files in builds

    Making Nix code, on average, much more reproducible by pervasive pinning

    Allegedly caching evaluation

    Possibly making Nix easier to learn by reducing the amount of poking at strange attribute sets and general NIX_PATH brokenness

    However, at the same time, there are a few things that one might be led to think about flakes that are not the most effective way of doing things. I personally use flakes relatively extensively in my own work, but there are several ways I use them that are not standard, with reason.

    Flakes are optional, and as much as some people whose salary depends on it might say otherwise, they are not the (only) future of Nix: they are simply a special entry point for Nix code with a built in pinning system, nothing more, nothing less.

    Nix continues to gather a reputation for bad documentation, in part because the official documentation for nixpkgs and NixOS is de facto not allowed to talk about flakes, as a policy. This situation is certainly partially due to a divide between Nix developers and nixpkgs developers, which are groups with surprisingly little overlap.

    Flakes also are a symptom or cause of much intra-community strife between “pro-flakes” and “anti-flakes” factions, but this situation is at some level a sign of broken consensus processes and various actors trying to sidestep them, an assumption by many people that the docs are “outdated” for not using flakes, and the bizarre proliferation of flakes everywhere in blog posts or tutorials leading to a belief that they are required for everything.

    This post is about how to architect Nix projects in general, with a special eye on how to do so with flakes while avoiding their limitations. It tries to dispel misconceptions that can develop in such a monoculture.

    Read all of Flakes aren’t real and cannot hurt you: a guide to using Nix flakes the non-flake way