[HN Gopher] Show HN: Flake schemas - teaching Nix about your fla...
       ___________________________________________________________________
        
       Show HN: Flake schemas - teaching Nix about your flake outputs
        
       Author : biggestlou
       Score  : 22 points
       Date   : 2023-08-31 15:35 UTC (7 hours ago)
        
 (HTM) web link (determinate.systems)
 (TXT) w3m dump (determinate.systems)
        
       | grhmc wrote:
       | Hey folks, this is Graham -- CEO of DetSys. Happy to help answer
       | any questions!
        
         | moojd wrote:
         | Thanks Graham! Glad to see some attempts at improving the dx of
         | sharing expressions with flakes instead of just derivations.
         | I've seen libraries and tools handle this in a ton of different
         | ways. Do you think there will ever be a standardization of the
         | 'lib' output?
        
           | grhmc wrote:
           | I hope there will be, but I'm not really sure. I think the
           | future of Nix is in smaller, focused flakes being shared and
           | exchanged. People dunk on projects like Rust and Node for
           | having infinity dependencies, but it is that way because
           | those ecosystems have rich library ecosystems that are worth
           | using. I see the same thing happening in Nix.
        
             | clhodapp wrote:
             | Regularization of more Flake outputs into schemas sounds
             | compelling. E.g. thanks to this great work on flake
             | schemas, do the definitions of outputs related to NixOS
             | modules, NixOS configs, and nixpkgs overlays even need to
             | be pre-baked into Nix?
             | 
             | In terms of this decomposition effort, one additional thing
             | that would be _really_ nice to see would be turning flake
             | URL schemes  & updaters extensible. One could imagine some
             | kind of a dictionary that maps from schemes to derivations
             | that contain the code needed to get the primitive URL for
             | the "latest" version of the flake when an update is called
             | for.
        
               | grhmc wrote:
               | I totally agree. This is one of the reasons we made
               | FlakeHub, to make a better update mechanism that was
               | flexible and supported things that aren't just github as
               | sources. I think that'll happen, it'll just take a bit of
               | time, and likely experimenting outside of nix before
               | patches land upstream.
        
         | dpc_01234 wrote:
         | Are flake schemas in any way compatible/conflict with Nickel
         | contracts?
        
         | slekker wrote:
         | Thanks for the awesome Nix installer and zero-to-nix! If you
         | don't mind my asking: what are your thoughts on tools like Flox
         | (floxdev) or Jetpack.io's Devbox? Do you feel like they are a
         | good approach for sharing dev envs inside a company? And is
         | DetSys working on something similar :^)?
        
           | grhmc wrote:
           | Thank you, you're welcome! I think those tools are
           | interesting, but a crutch / tape over difficulties that Nix
           | presents. I think that tools that try to hide a bad
           | experience with another layer often presents more problems in
           | surprising ways that sometimes leaves users with no option
           | but to undo all their hard work and start over. We did a
           | similar experiment last year with Riff, but haven't paid it
           | much attention because of the layering problem. Our focus is
           | making Nix and flakes themselves the best tool for the job.
        
       | VTimofeenko wrote:
       | Ooh, shiny! No more trying to remember how I usually nest home-
       | manager modules for custom stuff
        
       | mongol wrote:
       | I thought I started to understand flakes, but now I feel clueless
       | again.
        
         | zamalek wrote:
         | What are you struggling with? I've become okay at Nix and
         | flakes - so maybe I can help understand.
        
           | mongol wrote:
           | What does this enable that will be useful to me as a user?
        
             | rq1 wrote:
             | Better tooling, simpler interfaces, better error reporting,
             | validation... etc.
        
           | res0nat0r wrote:
           | I'm using NixOS again after installing it years ago and
           | enjoying it, but I still have a real hard time understanding
           | just how to somehow implement or use a flake, or create a
           | useful new package with it that isn't in the nixpkgs repo
           | already.
           | 
           | I still find much of the syntax incredibly confusing and hard
           | to just get simple concrete self contained examples, or
           | without worrying if this is intermingled with some non flake
           | code somewhere that isn't compatible.
           | 
           | I've bumped a few nix packages via github PR's and can hack
           | around a bit with existing things I see upstream, but knowing
           | how to do everything is still confusing.
           | 
           | I guess I need to sit down and read all of https://zero-to-
           | nix.com/ and see if there is anything I'm missing.
        
         | jljljl wrote:
         | Flakes have a set of default outputs they can generate, like
         | packages, devShells, templates, and NixOS configs. Nix knows
         | how these outputs work and can validate them using `nix flake
         | check`, or list them with `nix flake show`
         | 
         | But what if you want your flake to output a library? A
         | Dockerfile? A Terraform or Kubernetes config? Nix doesn't know
         | about those custom outputs, and doesn't have a way to validate
         | that you're using them correctly.
         | 
         | Now with Flake Schemas, you can provide a schema so that built
         | in tools like `nix flake show` and `nix flake check` can
         | properly validate the new output. This makes it easier for
         | Flake developers to communicate the interface of their custom
         | output to Flake consumers
        
           | alexeldeib wrote:
           | I'm modestly familiar with nix. I've written flakes and some
           | other derivations. I've dabbled with overlays and such but
           | I'm not super familiar. I liked flakes enough I created a
           | template repo for packaging dev envs.
           | 
           | Until this post/your comment I didn't know flakes could even
           | have custom outputs. I guess they're all just conventions for
           | attribute names, and everything is a derivation, so it makes
           | sense. But realizing that point was key, even with passing
           | nix familiarity.
        
         | grhmc wrote:
         | This is a deeper cut of pretty foundational stuff. Almost no
         | user will need to actually interact with schemas, and instead
         | will use schemas provided by other folks. In other words, if
         | this doesn't make sense: don't worry, you don't need to know
         | about it :).
         | 
         | The tl;dr, though:
         | 
         | * nix flake show and other tools only knew about very specific
         | types of things you might put in a flake.
         | 
         | * with flake-schemas, that limitation is lifted and people can
         | do more creative things.
        
       | pshirshov wrote:
       | > Flake schemas are not a type system for Nix, since that would
       | be a huge project.
       | 
       | The lack of a reasonable type system is one of the biggest Nix
       | problems.
        
         | rq1 wrote:
         | There's this https://github.com/tweag/nickel
         | 
         | Coupled with https://github.com/nickel-lang/organist
         | 
         | I'm not sure how immature it is though.
        
       ___________________________________________________________________
       (page generated 2023-08-31 23:02 UTC)