9 ms·

Show HN: FlakeHub – Discover and publish Nix flakes

154 points by grhmc 3y ago

grhmc 3y ago
Hey folks, Graham -- CEO of DetSys here. So glad to be able to share FlakeHub, our most ambitious project yet. FlakeHub brings a crates.io-like experience to Nix and flakes, with semver releases and publish-time checks to make sure the flake is easily distributable. Check it out, let us know what you think! I'll be here answering questions all day.
- foobarqux 3y ago
  I couldn't find a command line interface for searching the flakes, did I miss it?
  - grhmc 3y ago
    We don't have one yet, but watch for one in the coming weeks. The CLI we're putting together allows for searching and adding to your flake. You can search on the web UI, though: https://flakehub.com/search https://flakehub.com/search
- brunoqc 3y ago
  Isn't crates.io owned by The Rust Foundation?
  - SkyMarshal 3y ago
    "crates.io-like"
    - brunoqc 3y ago
      Would it make sense if crates.io was owned by a 3rd party? I don't think I would use it. So shouldn't flakehub be owned by The NixOS Foundation instead of being a 3rd party and proprietary? It seems to be a critical feature for flakes.
      - tazjin 3y ago
        Considering that flakes aren't a critical feature for Nix, it balances out.
        brunoqc 3y ago
        It's not? I thought that the NixOS creator calling flakes "the future of Nix", implied that it kinda was.
        tazjin 3y ago
        A thing with a clunky UI that technically only restricts the capabilities of its parent tool is not the future. It's a tarpit for staying in the local optimum that most Nix use is in right now.
        Macha 3y ago
        I don't see Flakes as a decision that's impossible to work past more or less than traditional nix, given that you can use flakes from traditional nix (not as easily as overlays, I will give you that), and frankly refusing to take a real improvement for end users over a hypothetical better one that no one has managed to produce yet seems counter productive.
        tazjin 3y ago
        You're talking about a different thing. I'm not interested in Nix for end-users who maintain office suite installations and Steam on their desktop computers. By all means, if somebody wants to make a great UX improvement for that - go ahead, but it doesn't need to be in the core of Nix.
        pxc 3y ago
        > It's a tarpit for staying in the local optimum that most Nix use is in right now. I know that pre-flakes conventions for reusing Nix code are pretty open-ended, and naturally 'pure evaluation mode' means turning a bunch of things off. I can also see how if you are interested in integrations with stateful systems or maybe relaxing certain constraints or allowing/tracking some 'impurities', that might also seem like a step in the wrong direction. Do you have any possibilities (or examples) in mind for how Nix might be used beyond the 'local optimum' of most current usage?
ryantmulligan 3y ago
Does it store artifacts or redirect to GitHub (or other) storage?
- grhmc 3y ago
  Good question. Publishing to FlakeHub makes an archive of the release, checks to make sure it evaluates cleanly in isolation, and publishes it to FlakeHub's storage. This is to make sure that releases stay available in the long term, even through GitHub account renames or repository deletions.
accelbred 3y ago
Are there plans to support uploads without github actions? I would be interested in it if it didn't require github and github-specific configuations like github action workflows.
- grhmc 3y ago
  Yeah, thanks. We only support GitHub Actions because of the authentication model it offer with JWTs. We're planning on expanding to support other forges, and eventually local publishing, too. In the meantime, you could use a GitHub action to clone your repository from another forge and publish it, if you wanted to.
  - accelbred 3y ago
    I see, so to confirm, I could have the workflow in a seperate repo than the repo I'm publishing? That would solve my concerns. I see in your docs that there is a repository config option, so that could work. If directory works with a submodule or repo pulled in previous job, that could also be an option. I'll give it a try later.
    - grhmc 3y ago
      Yep, that should work! Give it a try and let us know how it goes. Come join us on Discord, we'd be glad to chat about it.
  - SkyMarshal 3y ago
    > We're planning on expanding to support other forges, Just want to put in a request for SourceHut support in case it's not already on your list. Sometimes it gets overlooked in favor of the big corporate forges. https://sourcehut.org/ https://sourcehut.org/
    - grhmc 3y ago
      Thanks for sharing! We'll take a look. If nothing else, I'm sure you'll be able to publish using a CLI + token. Thanks!
rstarast 3y ago
The reception on the nixos discourse is worth a look: https://discourse.nixos.org/t/introducing-flakehub/32044 https://discourse.nixos.org/t/introducing-flakehub/32044
- grhmc 3y ago
  I just posted a reply on Discourse (https://discourse.nixos.org/t/introducing-flakehub/32044/14?u=grahamc https://discourse.nixos.org/t/introducing-flakehub/32044/14?...) but for posterity: I’m sorry some folks aren’t excited about FlakeHub, but that is okay. We’ve made it because it solves real problems we’ve experienced, and I think it is going to make a big difference in the community. We’re all contributing to the project in the ways we want to, and this is an example of that. We see flakes as the future of Nix, and we’re unabashedly working to make that true. One way we’re doing that is using flakes extensively every day and exposing ourselves to the bugs, papercuts, and pain points. We often deeply research and resolve these problems upstream, without fanfare or posting on Discourse. I think we have the common goal of growing and improving Nix, and we’re glad to be doing it together. We would love to see a continuation of RFC-144 accepted into Nix upstream. The version resolving feature of FlakeHub is a bandaid that works until the upstream project has a comparable feature. In my opinion, it is a good thing to do experiments like this without committing the entire project to it.
  - zamalek 3y ago
    As flawed as flakes are, they are significantly better than channels and all the hacks that surround them. Flakes are how I manage my system today and I honestly believe that there is no harm in building tooling around them - we all know that things are subject to change. This is now in my configs: https://codeberg.org/jcdickinson/nix/src/branch/main/flake.nix https://codeberg.org/jcdickinson/nix/src/branch/main/flake.n... Something I've noticed: `nixos/*` and `home-manager/*` are incompatible (home-manager expects 23.11 while nixos is 23.05).
    - grhmc 3y ago
      Very cool! You can get nixpkgs unstable like this: nixpkgs-unstable.url = "https://flakehub.com/f/NixOS/nixpkgs/1.*.tar.gz";
flexiondotorg 3y ago
Delighted to finally see FlakeHub out in the wild. Keen to answer questions, but if you'd like a direct community with the DetSys team we invite you to join us on Discord: https://discord.gg/invite/a4EcQQ8STr https://discord.gg/invite/a4EcQQ8STr
- toastal 3y ago
  We don’t want your proprietary Discord room—we want to see open options like an IRC chatroom, XMPP MUC, or Matrix Space.
aliasxneo 3y ago
I agree with @Infinisil's assessment[1]. This seems to summuarize my Nix experience in the last two years. So many products "fixing Nix" with little to no effort to upstream any of it. As a Nix consumer, it's frustrating because every one of these projects I chose to adopt is basically playing a huge game of risk. I've already had at least a couple of them deprecated/abandoned on me. Not saying it's a totally unique experience to Nix. It just seems especially concentrated at the moment. [1]: https://discourse.nixos.org/t/introducing-flakehub/32044/3?u=jmgilman https://discourse.nixos.org/t/introducing-flakehub/32044/3?u...
- jolux 3y ago
  It seems like the Nix community is already headed towards a soft fork. DetSys already provides their own Nix installer, and now FlakeHub. Jetpack has Devbox, which is an entirely different interface over flakes. I’m no Nix expert but I’ve used it enough to know that the hype exceeds the capabilities and especially the UX of the tool currently. (Just as an example, pinning versions that aren’t in the current nixpkgs release isn’t even possible right now without resorting to overlays and other hacks.) Frankly I’m glad that people are working to make it more user friendly. It reminds me a lot of when I first tried Stack for Haskell: packages just worked out of the box, no more tracking down arcane cabal-install errors and figuring out why it didn’t build in my machine.
  - rgoulter 3y ago
    > I’m no Nix expert but I’ve used it enough to know that the hype exceeds the capabilities and especially the UX of the tool currently. Nix has a higher difficulty curve, and rougher corners, than most tools out there. The onboarding experience can vary from "wow that was easy, this is incredible" to "this is easy to do with Linux, but why is this difficult on NixOS?". Nevertheless, Nix is a much more powerful tool for dealing with packages compared to what's widely used today. I don't think "overhyped" is deserved, even though someone new to nix will likely have difficulty trying to use it for everything. > Just as an example, pinning versions that aren’t in the current nixpkgs release isn’t even possible right now without resorting to overlays and other hacks I read this as "package foo v1.1 was in nixpkgs at some point, but's now foo v1.2". Not sure I'd use the term "hacks", but there are several ways you'd be able to refer to a v1.1 package, depending on what you're trying to do. But, yeah, if you want a different version than one that's provided by someone else, you're going to have to come up with something yourself.
trulyrandom 3y ago
I'm always excited to see developments in the Nix ecosystem, but I can't help but feel that this is a little bit tone-deaf. Nix flakes is a sensitive topic in the Nix community. Instead of spending time gracefully stabilizing the currently experimental feature, some of the core contributors to Nix apparently feel that doubling down and building a product on top of it instead is a better way to spend time. In addition, we're invited to join the discussion on Discord, of all places, instead of the other two standard messaging platforms that the Nix community typically uses (Matrix and IRC)
- theothershoe 3y ago
  As someone who is not listening in on the flake stabilization process, and who just wants to use Nix my thinking is, what's the alternative? To me it looks like people can either build on the feature that exists now, or put plans on hold for who knows how long while getting by with some lesser solution, passing up public enthusiasm that could be directed to growing the Nix ecosystem in the meantime. I'm getting the hint that some people aren't happy with the current state of flakes. But right now it's the best solution for a certain large class of problems so it's what people are going to go with. Again, as a relative outsider I see flakes as The Way Nix Works with the requirement of enabling experimental features just being a part of the Nix process. Nix is rapidly growing in popularity with a lot of people drawing the same conclusion as me. Maybe there is a better alternative to flakes in the horizon, and when it's ready I'll consider switching. But I'm not going to wait to use Nix in the meantime, and for me the best way to use Nix currently is flakes.
- grhmc 3y ago
  In our opinion, flakes are the future of Nix and we're doing the hard work of using them extensively everywhere we can. While we do that, we fix bugs and papercuts along the way. I don't think flakes _can_ meaningfully stabilize without people pushing them to their boundaries and then addressing the problems that come up. In other words, yes: we are doubling down because we don't see a future of Nix where flakes or something like them aren't central.
  - vegabook 3y ago
unshavedyak 3y ago
Wow, i wasn't interested at first because i'm already using flakes and i didn't think this had much value to me - i don't mind adding a flakes repo directly, for example. Then someone linked the discussion on Discourse[1] which has..: > FlakeHub not only indexes flakes, but provides a mechanism for fetching compatible versions based on Semantic versioning — and, unlike pinning tags in your flake.nix inputs, keeping them up to date. > This means that you can specify that you want your input to be compatible with whatever is the latest release at the time that you add it, and get bugfixes with every nix flake update, without manually having to keep track of the releases made upstream, nor follow a development branch which may introduce breaking changes at any time. Which is stupidly sexy to me. Semver-like is something i've been wanting so badly from Flakes/Nix. This has my attention now. [1]: https://discourse.nixos.org/t/introducing-flakehub/32044/6 https://discourse.nixos.org/t/introducing-flakehub/32044/6
- foobarqux 3y ago
  Something I've wanted is more customizable upgrade logic for selecting versions, especially upgrades for end-user packages. e.g. latest tagged release (without having to update the package/flake), latest tagged release but wait a week/month (like phased releases but end-user configurable), HEAD but no more than once a week (so you aren't compiling packages every day, c.f. emacs), whatever the latest version is provided it is in cachix, etc
- grhmc 3y ago
  I'm so glad you think so! We sure agree :). We're hoping this mechanism helps get some predictability, like that all the platforms that are listed fully evaluate as expected.
- mhio 3y ago
  Are you able to elaborate on some of the shade being thrown in that linked thread? There appears to be some politics around this, or determinate systems, or something.
  - unshavedyak 3y ago
    Not really, i don't follow it closely. I believe some others in this thread dive into it a bit. My (mostly assumed!) takeaway is that Flakes isn't perfect, and many existing users don't like that a very important part of Nix is being rushed. Conversely, many Flakes users think almost the exact opposite -- that Flakes has been taking too long and Nix is incomplete without it (i'm more in this camp). All around though i don't have the energy to partake in this holy war, so i mostly ignore it. I'm sure i am wrong on some important details, so please don't take what i say as more than it's worth.
aquova 3y ago
Perhaps a bit off topic, but I've been playing around with NixOS lately, and I don't understand what the advantages of using flakes are, or really what problem they solve. Granted, my interest in Nix is simply because I think it's cool to have the OS be configurable from a file, and I'm personally less interested in some of the reproducibility features. I've tried reading up[0] on some of the advantages of using them, but my eyes start to glaze over pretty quickly. [0] https://nixos.wiki/wiki/Flakes https://nixos.wiki/wiki/Flakes
- VTimofeenko 3y ago
  In a traditional nixos install you have two moving parts -- configuration.nix(and whatever modules it imports) and channels. Channels are updated independently which makes it harder to reason about the system at a specific point in time. Flakes unify the two in a common interface. You have the "channels"(called "inputs" in flakes) pinned and the "configuration.nix" (now one of the outputs) pinned together. That being said, you don't need to switch your system to a flake-managed one right away. If you enable the flags from that article, you can run things from flakes using "nix run". This will transparently pull the flake to your machine and evaluate the output you wanted.
  - SkyMarshal 3y ago
    > That being said, you don't need to switch your system to a flake-managed one right away. If you enable the flags from that article, you can run things from flakes using "nix run". This will transparently pull the flake to your machine and evaluate the output you wanted. That's where I am in my slow transition to flakes. Still basing my system on a monolithic configuration.nix, but with flakes enabled so I can experiment with them or use them in dev projects as opportunities arise. One day I'll get around to fully transitioning over to flakes, but it's nice that there's this intermediate step and no rush.
- rgoulter 3y ago
  A flake.nix file is somewhat comparable to a package.json file in a NodeJS project. Similar to how package-lock.json records the exact version of packages used to build a nodejs project, a flake lockfile will record the exact version of nixpkgs (and other nix dependencies) the flake uses. The other thing a flake.nix file provides is a consistent entrypoint to a codebase. Previously, by convention, projects might have a `default.nix`, but one default.nix might be a different form than another default.nix. The consistent entrypoint allows for a really nice UX for both referring to other nix codebases, as well as a Docker-like UX for running code which has a flake.nix.
toastal 3y ago
Flake utils as most people use it is often useless if not dangerous (leading users into errors you’ll now get bug reports for). To write a for loop over systems is 1–5 lines of Nix code instead of pulling in a dependency & it’s subdependencies. If you’re not testing systems, it might also not be wise to use defaultSystems & assuming it just works; often you are better served just picking the architectures you can test, or at least doing a union of the buildInputs’s support matrix.
jljljl 3y ago
This is awesome! We used a similar SemVer interface for installing standard nix packages on Nixhub (www.nixhub.io), and a lot of users told us it was a killer feature. Having a nice search interface should help a lot with Flake discoverability, which is currently a big challenge. Great work from the Determinate Systems team!
RyEgswuCsn 3y ago
Perhaps it is just me. But after so many attempts of trying to getting started with Nix, it is still not clear to me how to *author* Nix packages. My mental model about Nix is that it resembles make, but for the whole dependency graph. I kind of hoped that the Nix language is more sane. I think there is a project of similar goals but the script is in Python? I remember finding it once, but couldn't recall its name.
- SkyMarshal 3y ago
  Are you thinking of Dhall? https://dhall-lang.org/ https://dhall-lang.org/ https://news.ycombinator.com/item?id=32102203 https://news.ycombinator.com/item?id=32102203 https://news.ycombinator.com/item?id=31658638 https://news.ycombinator.com/item?id=31658638
  - RyEgswuCsn 3y ago
    Found it: https://github.com/spack/spack https://github.com/spack/spack
- rgoulter 3y ago
  > My mental model about Nix is that it resembles make, but for the whole dependency graph. Perhaps "Docker, without containers" would be a closer way to convey what Nix does. With Docker, images get built in a fresh/sandbox environment, and the resulting image is easy to distribute to other systems running Docker. > I kind of hoped that the Nix language is more sane. I think there is a project of similar goals but the script is in Python? A project quite related to "Nix (but not using a bespoke DSL)" is Guix, which uses Scheme. Perhaps you're thinking of Bazel? Which uses a Python-like language, and (AFAIU) is much closer to "like make, but for the whole dependency graph".
  - RyEgswuCsn 3y ago
    My understanding is that Nix was initially invented to solved the "producing builds with a fully specified dependencies graph" problem; people then figured out that it can dub as a package manager to support a better developer experience. Docker, on the other hand, was introduced to solve the deployment problem --- it provides light-weight isolation so that you get boggled in resolving dependency conflicts. Of course, people later also use it drive development environments, which I find quite sensible.
tezza 3y ago
Typo domain FakeHub is a leading porn portal, no?
- deleted 3y ago
  [deleted]
- grhmc 3y ago
  It's a tradition in the NixOS ecosystem, like nixos.com. (drat.)
colinsane 3y ago
i think i understand the problem this aims to solve, but why’s it a hosted web service instead of something more integrated into the traditional nix configuration system? nix has plenty support for referring to data via git tags, seems like a flake-level semver solver could be implemented locally — even without blessing from mainline `nix` — so long as the flakes you use label their inputs/dependencies accordingly.
OJFord 3y ago
What is Determinate Systems, the official group behind Nix? Not at all clear to me from the site: https://determinate.systems/ https://determinate.systems/ (Also, the support(?) phone number at the bottom seems pretty unusual!) Just trying to get my head around, as a Nix-interested non-user (other than toying with it briefly years ago) what Flake is, who it's from, how important the controversy mentioned elsewhere is, if I should care, if I'm just starting whether I should use it or not, etc.
- deadbunny 3y ago
  > (Also, the support(?) phone number at the bottom seems pretty unusual!) Ok Zoomer. (Sorry couldn't resist) So, old phones had letters on the digits (1 = ABC, 2 = DEF etc.) so you could have the phone number 555-GET-BEEF (555-438-2333) or whatever. Christ I feel old.
  - OJFord 3y ago
    No that's not what I mean, ha, I am aware of that. (Though it was never much of a thing in my non-US country, fwiw.) I meant having a phone number there struck me as unusual (for this sort of company/organisation).
  - SSLy 3y ago
    My "old phones" had a rotary encoder with no letters in sight. Trrrrrrrak trak trrrak…
evujumenuk 3y ago
Not to be overly facetious, but if SemVer is so great, then why do we hash the content of inputs at all? Just hash the `major` and `minor` components of the version number, since `patch` updates do not change observable behavior and/or spacebar heating is not a thing.
- rgoulter 3y ago
  SemVer is partly social and partly technical. -- Socially, with semver you're promising that the software (especially its interface) won't change too much. Technically, if function signatures change, or if implementation behaviour significantly changes (in ways that'd break old code), you want semver to indicate that. Nix's hashing of inputs solves a different problem. It wants to make sure you can have slightly different builds of packages available to the system. > ...since `patch` updates do not change observable behavior... Sure, the social guarantee of semver isn't enough to guarantee reproducible packages the same way Nix does, sure. But that doesn't mean that someone depending on v1.1.1 of a package would be happy to suddenly see v2.0.0, or that they'd be unhappy to see v1.1.2.
r3trohack3r 3y ago
For those who don’t know, edolstra (the person who posted this announcement on discourse) isn’t just some rando. They’re behind the (I believe to be original) Nix paper back in 2004: https://edolstra.github.io/pubs/nspfssd-lisa2004-final.pdf https://edolstra.github.io/pubs/nspfssd-lisa2004-final.pdf

154 points by grhmc 3y ago

Hey folks, Graham -- CEO of DetSys here. So glad to be able to share FlakeHub, our most ambitious project yet. FlakeHub brings a crates.io-like experience to Nix and flakes, with semver releases and publish-time checks to make sure the flake is easily distributable. Check it out, let us know what you think! I'll be here answering questions all day.

foobarqux 3y ago
I couldn't find a command line interface for searching the flakes, did I miss it?
- grhmc 3y ago
  We don't have one yet, but watch for one in the coming weeks. The CLI we're putting together allows for searching and adding to your flake. You can search on the web UI, though: https://flakehub.com/search https://flakehub.com/search
brunoqc 3y ago
Isn't crates.io owned by The Rust Foundation?
- SkyMarshal 3y ago
  "crates.io-like"
  - brunoqc 3y ago
    Would it make sense if crates.io was owned by a 3rd party? I don't think I would use it. So shouldn't flakehub be owned by The NixOS Foundation instead of being a 3rd party and proprietary? It seems to be a critical feature for flakes.
    - tazjin 3y ago
      Considering that flakes aren't a critical feature for Nix, it balances out.
      - brunoqc 3y ago
        It's not? I thought that the NixOS creator calling flakes "the future of Nix", implied that it kinda was.
        tazjin 3y ago
        A thing with a clunky UI that technically only restricts the capabilities of its parent tool is not the future. It's a tarpit for staying in the local optimum that most Nix use is in right now.
        Macha 3y ago
        I don't see Flakes as a decision that's impossible to work past more or less than traditional nix, given that you can use flakes from traditional nix (not as easily as overlays, I will give you that), and frankly refusing to take a real improvement for end users over a hypothetical better one that no one has managed to produce yet seems counter productive.
        tazjin 3y ago
        You're talking about a different thing. I'm not interested in Nix for end-users who maintain office suite installations and Steam on their desktop computers. By all means, if somebody wants to make a great UX improvement for that - go ahead, but it doesn't need to be in the core of Nix.
        pxc 3y ago
        > It's a tarpit for staying in the local optimum that most Nix use is in right now. I know that pre-flakes conventions for reusing Nix code are pretty open-ended, and naturally 'pure evaluation mode' means turning a bunch of things off. I can also see how if you are interested in integrations with stateful systems or maybe relaxing certain constraints or allowing/tracking some 'impurities', that might also seem like a step in the wrong direction. Do you have any possibilities (or examples) in mind for how Nix might be used beyond the 'local optimum' of most current usage?

ryantmulligan 3y ago

Does it store artifacts or redirect to GitHub (or other) storage?

grhmc 3y ago
Good question. Publishing to FlakeHub makes an archive of the release, checks to make sure it evaluates cleanly in isolation, and publishes it to FlakeHub's storage. This is to make sure that releases stay available in the long term, even through GitHub account renames or repository deletions.

accelbred 3y ago

Are there plans to support uploads without github actions? I would be interested in it if it didn't require github and github-specific configuations like github action workflows.

grhmc 3y ago
Yeah, thanks. We only support GitHub Actions because of the authentication model it offer with JWTs. We're planning on expanding to support other forges, and eventually local publishing, too. In the meantime, you could use a GitHub action to clone your repository from another forge and publish it, if you wanted to.
- accelbred 3y ago
  I see, so to confirm, I could have the workflow in a seperate repo than the repo I'm publishing? That would solve my concerns. I see in your docs that there is a repository config option, so that could work. If directory works with a submodule or repo pulled in previous job, that could also be an option. I'll give it a try later.
  - grhmc 3y ago
    Yep, that should work! Give it a try and let us know how it goes. Come join us on Discord, we'd be glad to chat about it.
- SkyMarshal 3y ago
  > We're planning on expanding to support other forges, Just want to put in a request for SourceHut support in case it's not already on your list. Sometimes it gets overlooked in favor of the big corporate forges. https://sourcehut.org/ https://sourcehut.org/
  - grhmc 3y ago
    Thanks for sharing! We'll take a look. If nothing else, I'm sure you'll be able to publish using a CLI + token. Thanks!

rstarast 3y ago

The reception on the nixos discourse is worth a look: https://discourse.nixos.org/t/introducing-flakehub/32044 https://discourse.nixos.org/t/introducing-flakehub/32044

grhmc 3y ago
I just posted a reply on Discourse (https://discourse.nixos.org/t/introducing-flakehub/32044/14?u=grahamc https://discourse.nixos.org/t/introducing-flakehub/32044/14?...) but for posterity: I’m sorry some folks aren’t excited about FlakeHub, but that is okay. We’ve made it because it solves real problems we’ve experienced, and I think it is going to make a big difference in the community. We’re all contributing to the project in the ways we want to, and this is an example of that. We see flakes as the future of Nix, and we’re unabashedly working to make that true. One way we’re doing that is using flakes extensively every day and exposing ourselves to the bugs, papercuts, and pain points. We often deeply research and resolve these problems upstream, without fanfare or posting on Discourse. I think we have the common goal of growing and improving Nix, and we’re glad to be doing it together. We would love to see a continuation of RFC-144 accepted into Nix upstream. The version resolving feature of FlakeHub is a bandaid that works until the upstream project has a comparable feature. In my opinion, it is a good thing to do experiments like this without committing the entire project to it.
- zamalek 3y ago
  As flawed as flakes are, they are significantly better than channels and all the hacks that surround them. Flakes are how I manage my system today and I honestly believe that there is no harm in building tooling around them - we all know that things are subject to change. This is now in my configs: https://codeberg.org/jcdickinson/nix/src/branch/main/flake.nix https://codeberg.org/jcdickinson/nix/src/branch/main/flake.n... Something I've noticed: `nixos/*` and `home-manager/*` are incompatible (home-manager expects 23.11 while nixos is 23.05).
  - grhmc 3y ago
    Very cool! You can get nixpkgs unstable like this: nixpkgs-unstable.url = "https://flakehub.com/f/NixOS/nixpkgs/1.*.tar.gz";

flexiondotorg 3y ago

Delighted to finally see FlakeHub out in the wild. Keen to answer questions, but if you'd like a direct community with the DetSys team we invite you to join us on Discord: https://discord.gg/invite/a4EcQQ8STr https://discord.gg/invite/a4EcQQ8STr

toastal 3y ago
We don’t want your proprietary Discord room—we want to see open options like an IRC chatroom, XMPP MUC, or Matrix Space.

aliasxneo 3y ago

I agree with @Infinisil's assessment[1]. This seems to summuarize my Nix experience in the last two years. So many products "fixing Nix" with little to no effort to upstream any of it. As a Nix consumer, it's frustrating because every one of these projects I chose to adopt is basically playing a huge game of risk. I've already had at least a couple of them deprecated/abandoned on me. Not saying it's a totally unique experience to Nix. It just seems especially concentrated at the moment. [1]: https://discourse.nixos.org/t/introducing-flakehub/32044/3?u=jmgilman https://discourse.nixos.org/t/introducing-flakehub/32044/3?u...

jolux 3y ago
It seems like the Nix community is already headed towards a soft fork. DetSys already provides their own Nix installer, and now FlakeHub. Jetpack has Devbox, which is an entirely different interface over flakes. I’m no Nix expert but I’ve used it enough to know that the hype exceeds the capabilities and especially the UX of the tool currently. (Just as an example, pinning versions that aren’t in the current nixpkgs release isn’t even possible right now without resorting to overlays and other hacks.) Frankly I’m glad that people are working to make it more user friendly. It reminds me a lot of when I first tried Stack for Haskell: packages just worked out of the box, no more tracking down arcane cabal-install errors and figuring out why it didn’t build in my machine.
- rgoulter 3y ago
  > I’m no Nix expert but I’ve used it enough to know that the hype exceeds the capabilities and especially the UX of the tool currently. Nix has a higher difficulty curve, and rougher corners, than most tools out there. The onboarding experience can vary from "wow that was easy, this is incredible" to "this is easy to do with Linux, but why is this difficult on NixOS?". Nevertheless, Nix is a much more powerful tool for dealing with packages compared to what's widely used today. I don't think "overhyped" is deserved, even though someone new to nix will likely have difficulty trying to use it for everything. > Just as an example, pinning versions that aren’t in the current nixpkgs release isn’t even possible right now without resorting to overlays and other hacks I read this as "package foo v1.1 was in nixpkgs at some point, but's now foo v1.2". Not sure I'd use the term "hacks", but there are several ways you'd be able to refer to a v1.1 package, depending on what you're trying to do. But, yeah, if you want a different version than one that's provided by someone else, you're going to have to come up with something yourself.

trulyrandom 3y ago

I'm always excited to see developments in the Nix ecosystem, but I can't help but feel that this is a little bit tone-deaf. Nix flakes is a sensitive topic in the Nix community. Instead of spending time gracefully stabilizing the currently experimental feature, some of the core contributors to Nix apparently feel that doubling down and building a product on top of it instead is a better way to spend time. In addition, we're invited to join the discussion on Discord, of all places, instead of the other two standard messaging platforms that the Nix community typically uses (Matrix and IRC)

theothershoe 3y ago
As someone who is not listening in on the flake stabilization process, and who just wants to use Nix my thinking is, what's the alternative? To me it looks like people can either build on the feature that exists now, or put plans on hold for who knows how long while getting by with some lesser solution, passing up public enthusiasm that could be directed to growing the Nix ecosystem in the meantime. I'm getting the hint that some people aren't happy with the current state of flakes. But right now it's the best solution for a certain large class of problems so it's what people are going to go with. Again, as a relative outsider I see flakes as The Way Nix Works with the requirement of enabling experimental features just being a part of the Nix process. Nix is rapidly growing in popularity with a lot of people drawing the same conclusion as me. Maybe there is a better alternative to flakes in the horizon, and when it's ready I'll consider switching. But I'm not going to wait to use Nix in the meantime, and for me the best way to use Nix currently is flakes.
grhmc 3y ago
In our opinion, flakes are the future of Nix and we're doing the hard work of using them extensively everywhere we can. While we do that, we fix bugs and papercuts along the way. I don't think flakes _can_ meaningfully stabilize without people pushing them to their boundaries and then addressing the problems that come up. In other words, yes: we are doubling down because we don't see a future of Nix where flakes or something like them aren't central.
- vegabook 3y ago

unshavedyak 3y ago

Wow, i wasn't interested at first because i'm already using flakes and i didn't think this had much value to me - i don't mind adding a flakes repo directly, for example. Then someone linked the discussion on Discourse[1] which has..: > FlakeHub not only indexes flakes, but provides a mechanism for fetching compatible versions based on Semantic versioning — and, unlike pinning tags in your flake.nix inputs, keeping them up to date. > This means that you can specify that you want your input to be compatible with whatever is the latest release at the time that you add it, and get bugfixes with every nix flake update, without manually having to keep track of the releases made upstream, nor follow a development branch which may introduce breaking changes at any time. Which is stupidly sexy to me. Semver-like is something i've been wanting so badly from Flakes/Nix. This has my attention now. [1]: https://discourse.nixos.org/t/introducing-flakehub/32044/6 https://discourse.nixos.org/t/introducing-flakehub/32044/6

foobarqux 3y ago
Something I've wanted is more customizable upgrade logic for selecting versions, especially upgrades for end-user packages. e.g. latest tagged release (without having to update the package/flake), latest tagged release but wait a week/month (like phased releases but end-user configurable), HEAD but no more than once a week (so you aren't compiling packages every day, c.f. emacs), whatever the latest version is provided it is in cachix, etc
grhmc 3y ago
I'm so glad you think so! We sure agree :). We're hoping this mechanism helps get some predictability, like that all the platforms that are listed fully evaluate as expected.
mhio 3y ago
Are you able to elaborate on some of the shade being thrown in that linked thread? There appears to be some politics around this, or determinate systems, or something.
- unshavedyak 3y ago
  Not really, i don't follow it closely. I believe some others in this thread dive into it a bit. My (mostly assumed!) takeaway is that Flakes isn't perfect, and many existing users don't like that a very important part of Nix is being rushed. Conversely, many Flakes users think almost the exact opposite -- that Flakes has been taking too long and Nix is incomplete without it (i'm more in this camp). All around though i don't have the energy to partake in this holy war, so i mostly ignore it. I'm sure i am wrong on some important details, so please don't take what i say as more than it's worth.

aquova 3y ago

Perhaps a bit off topic, but I've been playing around with NixOS lately, and I don't understand what the advantages of using flakes are, or really what problem they solve. Granted, my interest in Nix is simply because I think it's cool to have the OS be configurable from a file, and I'm personally less interested in some of the reproducibility features. I've tried reading up[0] on some of the advantages of using them, but my eyes start to glaze over pretty quickly. [0] https://nixos.wiki/wiki/Flakes https://nixos.wiki/wiki/Flakes

VTimofeenko 3y ago
In a traditional nixos install you have two moving parts -- configuration.nix(and whatever modules it imports) and channels. Channels are updated independently which makes it harder to reason about the system at a specific point in time. Flakes unify the two in a common interface. You have the "channels"(called "inputs" in flakes) pinned and the "configuration.nix" (now one of the outputs) pinned together. That being said, you don't need to switch your system to a flake-managed one right away. If you enable the flags from that article, you can run things from flakes using "nix run". This will transparently pull the flake to your machine and evaluate the output you wanted.
- SkyMarshal 3y ago
  > That being said, you don't need to switch your system to a flake-managed one right away. If you enable the flags from that article, you can run things from flakes using "nix run". This will transparently pull the flake to your machine and evaluate the output you wanted. That's where I am in my slow transition to flakes. Still basing my system on a monolithic configuration.nix, but with flakes enabled so I can experiment with them or use them in dev projects as opportunities arise. One day I'll get around to fully transitioning over to flakes, but it's nice that there's this intermediate step and no rush.
rgoulter 3y ago
A flake.nix file is somewhat comparable to a package.json file in a NodeJS project. Similar to how package-lock.json records the exact version of packages used to build a nodejs project, a flake lockfile will record the exact version of nixpkgs (and other nix dependencies) the flake uses. The other thing a flake.nix file provides is a consistent entrypoint to a codebase. Previously, by convention, projects might have a `default.nix`, but one default.nix might be a different form than another default.nix. The consistent entrypoint allows for a really nice UX for both referring to other nix codebases, as well as a Docker-like UX for running code which has a flake.nix.

toastal 3y ago

Flake utils as most people use it is often useless if not dangerous (leading users into errors you’ll now get bug reports for). To write a for loop over systems is 1–5 lines of Nix code instead of pulling in a dependency & it’s subdependencies. If you’re not testing systems, it might also not be wise to use defaultSystems & assuming it just works; often you are better served just picking the architectures you can test, or at least doing a union of the buildInputs’s support matrix.

jljljl 3y ago

This is awesome! We used a similar SemVer interface for installing standard nix packages on Nixhub (www.nixhub.io), and a lot of users told us it was a killer feature. Having a nice search interface should help a lot with Flake discoverability, which is currently a big challenge. Great work from the Determinate Systems team!

RyEgswuCsn 3y ago

Perhaps it is just me. But after so many attempts of trying to getting started with Nix, it is still not clear to me how to *author* Nix packages. My mental model about Nix is that it resembles make, but for the whole dependency graph. I kind of hoped that the Nix language is more sane. I think there is a project of similar goals but the script is in Python? I remember finding it once, but couldn't recall its name.

SkyMarshal 3y ago
Are you thinking of Dhall? https://dhall-lang.org/ https://dhall-lang.org/ https://news.ycombinator.com/item?id=32102203 https://news.ycombinator.com/item?id=32102203 https://news.ycombinator.com/item?id=31658638 https://news.ycombinator.com/item?id=31658638
- RyEgswuCsn 3y ago
  Found it: https://github.com/spack/spack https://github.com/spack/spack
rgoulter 3y ago
> My mental model about Nix is that it resembles make, but for the whole dependency graph. Perhaps "Docker, without containers" would be a closer way to convey what Nix does. With Docker, images get built in a fresh/sandbox environment, and the resulting image is easy to distribute to other systems running Docker. > I kind of hoped that the Nix language is more sane. I think there is a project of similar goals but the script is in Python? A project quite related to "Nix (but not using a bespoke DSL)" is Guix, which uses Scheme. Perhaps you're thinking of Bazel? Which uses a Python-like language, and (AFAIU) is much closer to "like make, but for the whole dependency graph".
- RyEgswuCsn 3y ago
  My understanding is that Nix was initially invented to solved the "producing builds with a fully specified dependencies graph" problem; people then figured out that it can dub as a package manager to support a better developer experience. Docker, on the other hand, was introduced to solve the deployment problem --- it provides light-weight isolation so that you get boggled in resolving dependency conflicts. Of course, people later also use it drive development environments, which I find quite sensible.

tezza 3y ago

Typo domain FakeHub is a leading porn portal, no?

deleted 3y ago
[deleted]
grhmc 3y ago
It's a tradition in the NixOS ecosystem, like nixos.com. (drat.)

colinsane 3y ago

i think i understand the problem this aims to solve, but why’s it a hosted web service instead of something more integrated into the traditional nix configuration system? nix has plenty support for referring to data via git tags, seems like a flake-level semver solver could be implemented locally — even without blessing from mainline `nix` — so long as the flakes you use label their inputs/dependencies accordingly.

OJFord 3y ago

What is Determinate Systems, the official group behind Nix? Not at all clear to me from the site: https://determinate.systems/ https://determinate.systems/ (Also, the support(?) phone number at the bottom seems pretty unusual!) Just trying to get my head around, as a Nix-interested non-user (other than toying with it briefly years ago) what Flake is, who it's from, how important the controversy mentioned elsewhere is, if I should care, if I'm just starting whether I should use it or not, etc.

deadbunny 3y ago
> (Also, the support(?) phone number at the bottom seems pretty unusual!) Ok Zoomer. (Sorry couldn't resist) So, old phones had letters on the digits (1 = ABC, 2 = DEF etc.) so you could have the phone number 555-GET-BEEF (555-438-2333) or whatever. Christ I feel old.
- OJFord 3y ago
  No that's not what I mean, ha, I am aware of that. (Though it was never much of a thing in my non-US country, fwiw.) I meant having a phone number there struck me as unusual (for this sort of company/organisation).
- SSLy 3y ago
  My "old phones" had a rotary encoder with no letters in sight. Trrrrrrrak trak trrrak…

evujumenuk 3y ago

Not to be overly facetious, but if SemVer is so great, then why do we hash the content of inputs at all? Just hash the `major` and `minor` components of the version number, since `patch` updates do not change observable behavior and/or spacebar heating is not a thing.

rgoulter 3y ago
SemVer is partly social and partly technical. -- Socially, with semver you're promising that the software (especially its interface) won't change too much. Technically, if function signatures change, or if implementation behaviour significantly changes (in ways that'd break old code), you want semver to indicate that. Nix's hashing of inputs solves a different problem. It wants to make sure you can have slightly different builds of packages available to the system. > ...since `patch` updates do not change observable behavior... Sure, the social guarantee of semver isn't enough to guarantee reproducible packages the same way Nix does, sure. But that doesn't mean that someone depending on v1.1.1 of a package would be happy to suddenly see v2.0.0, or that they'd be unhappy to see v1.1.2.

r3trohack3r 3y ago

For those who don’t know, edolstra (the person who posted this announcement on discourse) isn’t just some rando. They’re behind the (I believe to be original) Nix paper back in 2004: https://edolstra.github.io/pubs/nspfssd-lisa2004-final.pdf https://edolstra.github.io/pubs/nspfssd-lisa2004-final.pdf