-
-
Notifications
You must be signed in to change notification settings - Fork 2.6k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
book: Install helix declaratively from nixpkgs on NixOS #7064
Conversation
The problem in the chat you saw was actually related to the fact that they installed the nix package exactly as you described here and endedup with an ancient helix version (22.8) which caused issues. Not everyone uses nixpkg unstable. Since the flake is officially maintained I think it should definitly stay the recommended installation method. We could mentinom this as an alternative but warn that versions could be outdated |
The problem I saw in the chat, was that they thought it was either flakes or the highway. Flakes is considered experimental by upstream, but people are still jumping on the bandwagon left and right. If it helps, I can also provide instructions on how to install helix from nixos-unstable. |
e4aa074
to
7c1be2c
Compare
First of all, thanks to both of you for helping me install helix properly. I advocate for options in this case, it would be nice to display the main methods of installing the app to accomodate to the users needs/desires if we want more people to use helix (i do)
Tell me what you guys think |
Mentioning that Helix is available as
(and probably more I don't know about.) We mention the flake prominently because we maintain it in-repo as Pascal says, and it's easier to follow the latest changes and to create a custom build for yourself. I think it's certainly out of scope for Helix docs to be teaching NixOS. Mentioning nixpkgs and the unstable channel would be good though, and we could link out to the NixOS documentation for things like channels (https://nixos.wiki/wiki/Nix_channels) for further reading |
Yes, and that is kind of a flaw for new users, who don't have the mental model to process which of the million ways is better in their case. Many new users like me would like to have an opinionated "best-practice" way or a list of opinionated options so users don't seem frustrated, and yes, im still talking about helix, because each application has its optimal ways of installation (according to what the application itself is looking for)
I understand this point, this would useful to say which is the installation option chosen by the app, in this case flakes, from my pov as a newbie on nixos, flakes is more advanced and difficult way to use than other options. Taking this into account and that there are no installation steps (only a mention of where the installation source is located), to me it looks like a gigantic barrier for not so advanced nix users. If we want to suggest using flakes, we might as well have a tutorial on how to install it on your system, because this installation method, does not have a single command to this date. This would be comparable on the arch installation method of saying "helix is avaliable in the community repository" as it is, without any command, but instead we are using flakes and not pacman, a more difficult method (at least for newbies)
I agree to what i understood about this, we dont want to have a whole wiki dedicated to it, but we shall just tell enough to the user for them to install the app succesfully. In a way, the user could learn from this and therefore you would be teaching nixos. My position in this message is to make helix as available as possible to all types of users, promoting its growth. |
There is no preferred way to install helix on NixOS though, we simply support all the options. Flakes are the most popular (to keep in sync with master, or nix unstable to get latest release), but flakes are still marked as experimental and some users are still sticking to their old nix-env setups because of this. It's not up to us to teach users how to use their distros -- it's up to users to learn and make an educated choice. |
e.g. I'd be fine with this change if it dropped any command sequences and instead said "Helix is available in nixpkgs, unstable usually carrying the latest release. Helix is also available as a flake in the project root. " |
I get the ideal point, but what you are saying is not compatible with the position in my message Telling people "Go read the wiki, educate yourself until you know how to install it by yourself, then come back and install" is not a good idea if you want people to use your app, if you do that many people will say "ok let's use neovim then" and simply leave Having an opinionated option does not mean necessarily we are interfiering with the user's choice, but offering a choice to those who don't feel safe enough to make a decision by themselves or install by themselves. And generally there are unpreferred ways for the nixos system (this obv can change drastically between apps) like for example nix-dev, which does not take advantage of the capabilities nix offers which you would take advantage of by using declarative methods |
Why does this have to be Helix's responsibility rather than Nix/NixOS/nixpkgs? If you feel uncomfortable editing your Nix things, perhaps you should take the time to learn those tools first, so that you don't need to rely on each individual application you are interested in providing a copy-pastable code snippet for every possible installation method. Since there are so many ways to make a program available on a system running Nix/NixOS, I think something vague like what was suggested here is optimal: it states the places the derivation can be sourced from and leaves the user to decide exactly how they want to consume it.
I don't think this is a valid argument because, at least hypothetically, you wouldn't know how to do that anyway. It's a completely empty threat. |
It simply does not have to be, but it can I'm trying to provide a solution here because i can, and because helix could, not because it should We, if we consider ourselves as part of helix, could make it easier for users to install helix, we could compensate for the lack of good docs of nixos/tutorials or whatever This is logical if we want helix to be used more, saying no to it because we should not and they should does not solve a thing,
I'm interpreting that when you said "you wouldn't know how to do that anyway" you were referring to "ok let's use neovim then", |
It shouldn't be.
Right, this is the crux of the issue. The way to alleviate this is to improve the Nix/NixOS/nixpkgs documentation. Trying to "compensate" for this situation in your suggested way will continue to result in this exact same problem, except with a different program instead of Helix. Making direct improvements to Nix/NixOS/nixpkgs documentation will make it easier for knowledgeable parties to keep track of and maintain, and easier for new users to find information and learn from it. Scattering this sort of information around like this PR currently does is actively detrimental to the class of problem you (and others) are having. (Nix/NixOS could really use something like this section from the Arch Wiki...) Miscellaneous points
The premise of this is invalid because you could apply it to any program. You should want every program's Nix/NixOS installation methodology to be equally well-documented so that this isn't something to compete on in the first place.
If you're on NixOS, this is not the right action to take.
This is not true; they are both packaged in nixpkgs. |
You are right |
This is really the most simple way, and helix is well maintained in nixpkgs.
Updated with that in mind. |
Thanks y'all! |
This is really the most simple way, and helix is well maintained in nixpkgs.
The flake solution is overly complicated for newcomers to NixOS, as I just
witnessed on our support room. Copying/adapting/understanding that
expression is far easier.