[HN Gopher] Show HN: FlakeHub - Discover and publish Nix flakes
___________________________________________________________________
Show HN: FlakeHub - Discover and publish Nix flakes
Author : grhmc
Score : 121 points
Date : 2023-08-22 15:29 UTC (7 hours ago)
(HTM) web link (flakehub.com)
(TXT) w3m dump (flakehub.com)
| grhmc wrote:
| 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 wrote:
| I couldn't find a command line interface for searching the
| flakes, did I miss it?
| grhmc wrote:
| 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
| brunoqc wrote:
| Isn't crates.io owned by The Rust Foundation?
| SkyMarshal wrote:
| "crates.io-like"
| brunoqc wrote:
| 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 wrote:
| Considering that flakes aren't a critical feature for
| Nix, it balances out.
| brunoqc wrote:
| It's not? I thought that the NixOS creator calling flakes
| "the future of Nix", implied that it kinda was.
| tazjin wrote:
| 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 wrote:
| 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.
| rmorey wrote:
| I don't think Nix really has a viable future without
| flakes
| SkyMarshal wrote:
| Oh I see what you mean, I misunderstood your comment.
|
| Yeah I'm not sure what would be best in this regard.
| Flakes are on track to becoming a critical feature for
| Nix, though I'm not sure Flakehub will be a critical
| feature for Flakes. It seems there are some issues with
| standardization of pinning and versioning that need to be
| fixed in upstream, but the Flakehub folks seem committed
| to transitioning to those when fixed:
|
| https://discourse.nixos.org/t/introducing-
| flakehub/32044/14
|
| As long as those standards get worked out upstream and
| Flakehub and similar projects follow them, and they're
| technically interchangeable, then they may be ok. It's if
| there are a bunch of different proprietary solutions with
| different proprietary standards where it becomes
| problematic.
| flexiondotorg wrote:
| 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
| toastal wrote:
| We don't want your proprietary Discord room--we want to see
| open options like an IRC chatroom, XMPP MUC, or Matrix Space.
| aliasxneo wrote:
| 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...
| beefee wrote:
| Me too. Several teams are trying to land grab by "wrapping" Nix
| with extra stuff.
|
| But as good as flakes are, they still have big problems.
| flake.lock size explosion, UI hassles, no cross compiling
| support.
| jacoblambda wrote:
| Yeah it's less than ideal however FWIW graham's comments [1]
| seem to indicate that this project stemmed out of fairly rapid
| development over the course of a weekend with some additional
| time taken to polish it up.
|
| If that's the case they may see this as some easy duct tape
| over top of flakes that could take the pain off of flakes
| itself while flakes actually work through the process of
| stabilizing.
|
| [1] https://discourse.nixos.org/t/introducing-flakehub/32044/7
| grhmc wrote:
| That's largely right. Getting semver version solving into Nix
| core itself is a goal of ours. FlakeHub implements it server-
| side because landing it in Nix without proving it out
| conceptually would be really hard, and also -- in my opinion
| -- reckless. Trying these things out in the world without
| committing the project to it long term is a good thing.
| mongol wrote:
| I think there is a perception that if problems like that
| are first solved in a proprietary service rather than in
| core tools, it may in extension tie the ecosystem to that
| service, while at the same time lessen the need to solve
| problems in the foundation. Even if this perception is
| wrong, I think it exists and why you see concerns raised in
| this thread.
| grhmc wrote:
| These are indeed valid concerns, and I think that it's
| fair for the community to be vigilant about such things
| and to ask probing questions. But my perspective is both:
|
| - Nothing we're doing is inherently proprietary or
| "secret sauce". FlakeHub isn't doing anything magical,
| and the version solving feature would be better if Nix
| did it itself.
|
| - Also, proprietary services can serve important
| functions in OSS communities. They can expand the user
| base significantly (like GitHub to Git) and they can send
| signals to maintainers of official tools about what's a
| hit and what's a dud. And I think that that's precisely
| what we're doing not just with FlakeHub but also with the
| Determinate Nix Installer, the Magic Nix Cache, the Flake
| Checker, and others.
| pxc wrote:
| I really want to think the best of DetSys, and I use some of
| their work and love it. Some people who work at DetSys have
| been prolific contributors in the Nix community as long as I
| can remember. I also understand the urge (and precedent, within
| the Nix community) to go off and build your own thing to
| experiment.
|
| But I think with the general pain and anxiety many longstanding
| community members are feeling over increasing commercial
| investment in Nix as well as the whole design and rollout of
| flakes, more upstream-first development would go a long way (as
| would quickly making good on statements of interest to upstream
| these features).
| grhmc wrote:
| I know folks have anxieties about commercial investment, and
| anxieties about developing flakes. Whenever we hit bugs in
| flakes, we go work upstream to fix them. We do this rather
| often :).
|
| I won't try to persuade you one way or another on commercial
| investment other than it is here with or without DetSys, and
| we've released a rather large suite of tools to make using
| Nix more pleasant and all but one (flakehub's backend) is
| free and open source. I feel that is a good way to go!
|
| I also think developing features and improvements to Nix
| outside of it is a good way to prove out ideas that can be
| eventually merged in to core. We don't _want_ to be solving
| the version on the server, but I'm rather sure it would have
| taken months if not years to get an experiment merged. And
| for good reason: we all want to make sure what goes in to Nix
| is solid.
| pxc wrote:
| > I also think developing features and improvements to Nix
| outside of it is a good way to prove out ideas that can be
| eventually merged in to core.
|
| I think it definitely can be. Naturally, more DetSys code
| and ideas that go through that whole journey, the more
| likely Nixers will be to reflexively trust the company when
| it comes to new projects. I'm optimistic that that can turn
| out well.
|
| > we've released a rather large suite of tools to make
| using Nix more pleasant and all but one (flakehub's
| backend) is free and open source. I feel that is a good way
| to go!
|
| I think open-core and proprietary services based on F/OSS
| can be an effective business model that helps get valuable
| open-source work done.
|
| For me, Red Hat's model and Qt-style dual licensing are
| even more attractive because they are based on
| comprehensive F/OSS licensing.
|
| That said, companies have to figure out licensing
| strategies that make sense for them and the particular
| markets and software they're dealing with. I don't
| begrudge, e.g., Determinate Systems or Cachix or Hercules
| taking up strategies that involve proprietary services
| because I've seen people involved with all three companies
| continue to make important contributions to Nix, Nixpkgs,
| and F/OSS tooling in the ecosystem that's about more than
| just plugging into those services. That signals good faith
| engagement to me.
|
| But seeing stuff like version management get handled in
| bespoke ways in proprietary services like FlakeHub or at
| Flox when it remains unaddressed in Nix itself naturally
| raises an alarm, though.
|
| > We don't _want_ to be solving the version on the server,
|
| I feel like that's good sense architecturally.
|
| Seeing this problem solved in Nix itself will help
| establish a record and reputation.
| mongol wrote:
| I will try to put myself as an outsider and just reflect on
| what I see. We have a very innovative Linux distribution /
| packaging etc software, where there is no dominant commercial
| actor. Instead there are a number of smaller companies
| specializing in evolving the ecosystem, selling services around
| it and so on. There is opportunity in Nix future for a
| commercial actor to make a lot of money by becoming the most
| trusted authority in aspects of it. Becoming the next Red Hat
| or something like that. I sense there is a lot of positioning
| and hustling to become THE Nix company that takes pole position
| and becomes the dominant one.
|
| Once in a while, there have been an announcement like this,
| which has not been well received. I am a little worried about
| it, and what it can lead to for the future. I worry it can
| split the community and be harmful to the future of very
| innovative software. I am trying to think of a similar
| situation within another area of the Linux or Open Source
| space, but can't really come up with good examples.
|
| Interested to hear if these thoughts are well founded or just a
| bad take.
| grhmc wrote:
| We strongly value open source software through and through,
| and have a team of long term contributors to open-source
| projects and communities. Part of open source is being
| allowed to build and experiment and see what happens. I find
| it unfortunate that people respond so strongly to our work,
| but I think part of it is a bit of fear of the unknown. We've
| published a lot of tools that we think are really nice, and
| almost all of them are totally open source and free (though
| the flakehub.com backend currently is not). Hopefully in the
| end the proof is in the pudding.
| jolux wrote:
| 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.
| soraminazuki wrote:
| Every piece of technology is incapable of doing anything if
| you label all solutions as "hacks."
|
| Here's proof:
|
| Is it possible to write C programs that manipulate strings?
| No, because string library functions are "hacks." Is it
| possible to write a bash script that passes arguments with
| spaces to a command? No, because quoting and character
| escaping are "hacks."
|
| Nix packages are malleable. With a bit of code,
| customizations can be applied to individual packages and
| entire dependency closures alike. An overlay is an embodiment
| of this property. It allows the user to create packages that
| fits their unique needs on the fly without having to
| repackage the whole world. No other package manager maybe
| besides Guix has this capability. I don't think it's fair to
| dismiss it as an "hack."
| rgoulter wrote:
| > 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.
| jolux wrote:
| > 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.
|
| Yeah, this is the part I find a bit silly. There should be
| one way to do this. What I want to do is pin an Erlang
| version (down to semver patch) and then pin an Elixir
| version that's compatible with it (also to semver patch).
| This is trivial to do with my existing tools (asdf/rtx and
| Dockerfiles), but it doesn't have first-class support in
| Nix. I have to build that capability myself! I was
| absolutely floored by this after hearing so much about how
| seriously Nix takes reproducibility.
|
| Similarly, the default Elixir and Erlang packages don't
| even have a version, you have to use one of the special
| elixir_1_14 packages to get a specific minor version. The
| default Elixir just gets the latest release at the time
| nixpkgs was released. I can pin nixpkgs trivially but it's
| not intuitive to pin individual packages across nixpkgs
| releases. Clearly this is just how Nix works, but because
| it's not how any other dependency managers work, it's a lot
| harder to integrate piecemeal.
|
| edit: to Jetpack's credit, this is one of the things I
| really like about Devbox. It makes pinning minor versions
| easy!
| pxc wrote:
| > DetSys already provides their own Nix installer
|
| That installer has actually been developed with community
| collaboration from outside DetSys from early on in its
| lifecycle via the Nix Installer Working Group1, which
| includes stakeholders from other companies and whoever else
| volunteered to get involved.
|
| I haven't followed it super closely recently, but to the best
| of my knowledge DetSys has done a good job with that project
| of orienting themselves towards the wider community and
| upstreaming that work.
|
| FWIW, the maintainer of and chief contributor to that project
| is also extremely responsive to community activity on GitHub
| as well. I reported a few bugs the other day and was frankly
| delighted by how it went. It's being developed in the open,
| like _proper_ open-source. The Determinate Nix Installer is
| not at all a 'let's do this in-house, behind closed doors,
| then throw it over the fence' kind of effort.
|
| --
|
| 1: https://discourse.nixos.org/t/nix-installer-
| workgroup/21495/...
| jolux wrote:
| Oh yeah, I have no criticisms with how that project is
| being run. But obviously they still decided to launch it
| instead of working to upstream it.
| biggestlou wrote:
| Point of clarification: we are fully open to upstreaming
| the installer in whole or in part and have been from the
| get-go.[^1] But the installer is a pretty radical
| departure from the current official installer. The
| official installer is written in Bash; the DetSys
| installer is written in Rust. The official installer
| targets fairly "standard" platforms; the DetSys installer
| has experimental support for things like the SteamDeck.
| And so on.
|
| We think it's perfectly okay to have that kind of
| distribution of labor in OSS, where core/upstream things
| need to be extremely stable and conservative while the
| community runs experiments and figures out what works and
| doesn't.
|
| [1]: https://determinate.systems/posts/determinate-nix-
| installer#...
| [deleted]
| ryantmulligan wrote:
| Does it store artifacts or redirect to GitHub (or other) storage?
| grhmc wrote:
| 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.
| aquova wrote:
| 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
| VTimofeenko wrote:
| 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 wrote:
| _> 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 wrote:
| 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 wrote:
| 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.
| RyEgswuCsn wrote:
| 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.
| jaculabilis wrote:
| nix.dev added a new tutorial for that recently:
| https://nix.dev/tutorials/learning-journey/packaging-existin...
| lagrange77 wrote:
| > My mental model about Nix is that it resembles make, but for
| the whole dependency graph.
|
| I just started learning about nix a few days ago. I'm still a
| little bit confused and flakes are an abstraction, i didn't
| tackle so far.
|
| My mental model is, that it resembles sth. like virtual
| environments for python or nvm for node.js installations. At
| least that's what i want to use it for.
| SkyMarshal wrote:
| Are you thinking of Dhall?
|
| https://dhall-lang.org/
|
| https://news.ycombinator.com/item?id=32102203
|
| https://news.ycombinator.com/item?id=31658638
| RyEgswuCsn wrote:
| Found it: https://github.com/spack/spack
| rgoulter wrote:
| > 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 wrote:
| 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.
| Smaug123 wrote:
| Personally I think of Nix mainly as analogous to "the part
| of Docker which concerns itself with producing the OCI
| artefact", but in a much less cursed way than via
| Dockerfile and `docker build`. (`docker build` is
| inherently cursed by design; `nix build` is cursed only
| through incidental facts about Nix, and it would be
| possible in principle to write a non-cursed frontend for
| it.)
| accelbred wrote:
| 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 wrote:
| 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 wrote:
| 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 wrote:
| 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 wrote:
| _> 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/
| grhmc wrote:
| 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!
| trulyrandom wrote:
| 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)
| [deleted]
| grhmc wrote:
| 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 wrote:
| you guys seem very <ahem>, determined, to do things your way.
| I'm kinda new to the whole nix community and it just feels
| like you guys are a bull in a china shop. Maybe that's what
| it needs. Strong, opinionated, decisive, leadership. Dunno.
| All I can say is I hope, I _really_ hope, that you guys don't
| become, basically, Nix's "google". Defacto owning it to all
| of our costly detriment over time. It's why I'm tempted,
| despite their polish, to stay away from your products for the
| time being.
| grhmc wrote:
| My feeling is we've been careful and considered about what
| we build and why, though I understand some folks don't like
| what we've made. That's their right, just like it is our
| right to build things we think are important and add value
| to the Nix community. We're not in charge of the Nix
| project: Nix has its own governance and processes that we
| also engage with.
|
| Most of our tools are open source, totally free, and don't
| depend on us as a company continuing to exist. In many
| cases I hope the Nix project wants to adopt and take over
| some of our work -- like the installer.
|
| Our goal is to make Nix as good as possible, and do it
| together. In the meantime, it's okay to not use our tools
| :)
| Macha wrote:
| Honestly, after seeing a little bit of how the sausage gets
| made and where the gridlock in Nix comes from, I think
| that's kind of needed.
| aidenn0 wrote:
| > 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.
|
| Eh, they had a pain-point, built a tool to alleviate it, and
| shared it. I suppose the less tone-deaf alternatives are "keep
| feeling the pain (by not building it)" or "let everybody else
| keep feeling the pain (by not sharing it)." I can't complain
| too much with that.
|
| > 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)
|
| 100% with you on this point.
| theothershoe wrote:
| 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.
| jljljl wrote:
| 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!
| tezza wrote:
| Typo domain FakeHub is a leading porn portal, no?
| grhmc wrote:
| It's a tradition in the NixOS ecosystem, like nixos.com.
| (drat.)
| [deleted]
| colinsane wrote:
| 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.
| rstarast wrote:
| The reception on the nixos discourse is worth a look:
| https://discourse.nixos.org/t/introducing-flakehub/32044
| grhmc wrote:
| I just posted a reply on Discourse
| (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 wrote:
| 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: http
| s://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 wrote:
| Very cool!
|
| You can get nixpkgs unstable like this:
| nixpkgs-unstable.url =
| "https://flakehub.com/f/NixOS/nixpkgs/1.*.tar.gz";
| unshavedyak wrote:
| 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
| foobarqux wrote:
| 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 wrote:
| 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.
___________________________________________________________________
(page generated 2023-08-22 23:01 UTC)