my feedback as someone who hasn’t used it, and … sorry, will never use it, since I am not the target audience.
The documentation seems very good, as to what it is and how do install/use it seems very simple and clear.
The commands also seems very clear and well thought out. The webpage design is also very well done!!
Congrats on the presentation… It makes me want to use it !!!
In my opinion, again, as someone who hasn’t used it and 99% probably never will, and in my non important opinion, I see this as a great thing. coupled with calamares installer + fleek that seems easy and slick way to manage packages, it could reach people that like or want this usage. I see probably some people then move to nix or nickel when available, or just keep it like this, and not do any kind of coding.
Either if it is nix / nickel / scheme / haskel / assembly / whatever or YAML, I think the important thing is to allow NON IMPERATIVE ways to manage the system.
Just my non important opinion, from a non important person.
@bketelsen awesome project ! I have just tried fleek while setting up a new Mac and together with DeterminateSys’s installer (thanks to @grahamc and his team) this was the kind of UX that will take Nix to the next level
Note that I’m pretty experienced with Nix (over 6 years) and I find this super useful, so I don’t think the target would be only new Nix users
Minor comments:
I think it would be nice if fleek add <pkg> would check if the package actually exists, this will make it slower but prevents doing few adds then having to check what was the wrong pkg.
maybe a fleek edit subcommand can be added which opens ~/.fleek.yml in $EDITOR
is there a way to see the nix or home-manager commands executed ? if not yet available, might be nice to have that when some environment variable is set or simply through --verbose
I might come up with more feedback as I continue using
Just to clarify, since it seems like a lot of folks chiming in here did not look at fleek’s actual features:
Fleek allows configuration via nix files for those that want that in addition to the yaml basic config.
Fleek also prominently notes a feature that helps you migrate from fleek to standard home-manager config once you become comfortable with nix and no longer want to use it. In my opinion, that’s an incredible feature, and one that makes it much easier for me to recommend nix and home-manager to people to try out.
While the nix language may arguably be simple and elegant, nixpkgs and home-manager are complex enough that I’ve seen them turn away many people (including myself multiple times in the past), so having an easy way to start with a straightforward migration path to the standard way seems incredibly valuable to me.
This project is amazing! I think its great to have a simple onboarding process to start getting the benefits of declarative environments without having to understand nix. And the fact that any point you can eject the config into pure nix means that complexity isn’t hidden and there is encouragement to understand complexity when you have the context and time/energy to do so.
As someone who’s not a regular user of Home Manager, I saw the modest announcement which suggested to me that this was in really early stages, read that this was a wrapper for HM, read the comments that were about the YAML configuration files, and figured it probably wasn’t for me. I mentally set it aside pending subsequent releases, more substantive discussion, or some other reason to check it out.
Then tonight, I stumbled upon a link to the Fleek website and I was super confused. It went something like this:
Didn’t I remember seeing a Discourse post about a really new project of that name? This couldn’t be it.
That project was barely getting started… but this one has a really nice website! Weird.
That project was for people who wanted to avoid the Nix language… but this one has this super cool eject subcommand for exposing its configuration natively in the Nix language and a NixOS-like module system, with all their usual flexibility and power. Wow.
That project was for people who use Home Manager… but this looks like an awesome replacement for my current usage of nix profile for semi-permanent changes when I don’t want to bother to open an editor. Huh.
What the hell happened?? Are there two projects with the same name? Did I trip out and mistake a year old post for a days old post the other day?
Needless to say, I really had the wrong idea about what this project was for, how ready it is for testing, and whether I was in its intended audience. lmfao
I look forward to messing around with this tomorrow when I want to avoid some other work.
List of strings with each corresponding to the package name. This won’t help you with overrides but it gets you far.
Here in the end we will want to have say the module system as a front-end. And I can very well imagine even a tool such as fleek in front of that or in conjunction, that is, configuring through the module system using both nix and toml.
Seems like a lot of this discussion is yet another convention over configuration debate. Yes, an opinionated framework introduces some limitations— its expectations (interfaces) are necessarily going to be narrower than the full scope of all possible styles in the language. For some things, this will make it a bit worse.
But it also spares people using it from the cognitive burden of making a lot of choices that, in use cases most suited to the framework, are not super relevant to the developer’s primary task. And those simplifications also enable the creation of handy CLI tools, which benefit from being able to rely on more assumptions about the code they’ll be operating on. They can also help developers onboard to new projects just because those projects will look more familiar.
The tastes of individual users/developers vary, and so do the needs of individual projects. But to me, it’s clear that sometimes the constraints of a simplified interface like this buy real wins. Rails is obviously a famous example. But I think we already have our own as well in Nix, like
flakes vs. the many old ways to pin packages and distribute Nix code in Nix 2.3
using an overlay in your Nix config repo so that your out-of-tree packages can be structured on the filesystem just like packages in Nixpkgs, making PRs easy when the time comes
consuming somebody else’s flake’s .lib output instead of poking through their source tree to figure out what to import
Maybe you can think of other examples. It’s totally valid not to prefer the more constrained, opinionated interface in any given case, or even in all cases. But at the same time I do think the orientation of such simplifying, limiting approaches is clear— how for the right audiences with the right use cases, they credibly hope to add value.
The same kind of tradeoffs applies to all of that, btw, whether the code the tool in question generates or reads for its special uses is Nix (like in Haumea), JSON (like in your flake’s lock file), TOML (like in devshell), or YAML (like you can see used variously here, in devbox, in devenv, and probably elsewhere).
The big problem I see here, is that sometimes a YAML string means packageattribute in pkgs and sometimes is indeed a string, and in other situations it will probably translate into a path-literal.
Doesn’t this increase cognitive load? I need to know each fields meaning to know how the YAML string will be interpreted?
And I still can’t find any relevant documentation that tells me how to actually do anything… It is still just linking the HM appendix, without any explanation how to translate that into fleeky YAML.
I do not see how this improves things.
Still, other people seem to, as I’ve heard fleek gets actually used by real people. I will probably never understand the why, but I hope it works as an “entrydrug” for them.
it really doesn’t increase cognitive load if you just want it to manage packages. It’s got some work when it comes to not automatically managing your bashrc/zshrc aggressively though, you have to put things in user.nix to have it just source a file / manage it through home-manager configs.
outside of that it’s a pretty nice tool, especially for people who aren’t wanting to learn nix syntax – I had it up and going in a few minutes after probably 16 months collectively grappling with nix because the documentation is scattered and best practices have changed nine times in two years. Home-manager already requires learning “more than nix” if you’re off the beaten path, making this… not actually bad comparitively.
I’m deeply saddened by how much useful discussion could have been in this thread, could have maybe been useful for me trying to find those parts that instead was killed in the cradle, at least on the forum. All because people who refused to even read or use it started the uninformed complaints.
not everyone wanting to use nix is a full time software dev, or someone with a lot of free time.
There are plenty of wrappers around Nix, which one will stand the test of time? Maybe it’s best to simply learn Nix?
I saw that the repo was in the ublue-os repo, so read up about what it was.
According to Jorge, Bluefin “is me and some friends taking uBlue and then making it our own – this is where I make stronger opinionated decisions, the Ubuntu-style dock and app indicators, and a ChromeOS-like maintenance cycle. For devs, it includes a bunch of cloud tools like Kubernetes’ kind. The overuse of cloud terminology is on purpose, I’m trying to use known-proven tech from cloud on the desktop for reliability and features, so you’ll see all the usual cloud-native words in there, good for SEO.”
I’m personally not a cloud-native person, but as long as the people developing this yml wrapper can actually maintain it, then there’s no real problem. This seems like an interface for the people who like cloud-native thinking and culture, which I am not, but others may be.
