Within the span of a afternoon and a bit a reading I went from zero, to a script that lets me setup an entire dev systems with just a few commands in a vm, and or even on hardware.
If anything the Nix documentation is just as good as every other thing out there. What is different is there are more than one way to do many things in Nix. This to me I think is the core of complaints. Its a language, and thus the language has may expressions that result in the same outcome.
The second bit I think people struggle with is it is functional. If you look at Nix complaints they appear to nearly be identical to that of Haskell.
I would never recommend nixos to anyone. The concept is awesome, but the execution is terrible.
> How do I create a nix package that clones eMacs from GitHub and builds it from source?
{ pkgs ? import <nixpkgs> {}, fetchFromGitHub }:
let
emacsSrc = fetchFromGitHub {
owner = "emacs-mirror";
repo = "emacs";
rev = "master";
sha256 = "0xabcd1234";
};
name = "emacs";
version = "27.1";
src = emacsSrc;
buildInputs = [ pkgs.autoconf pkgs.make ];
configurePhase = ''
autoconf
./configure --prefix=$out
'';
buildPhase = "make";
installPhase = "make install";
}Am I right in assuming this is a ChatGPT misunderstanding, or is it a wildcard SHA256 in nix to allow any download?
First it's a distribution and a package manager, and the guidance regarding these is sub-par. Especially with what there is of documentation being split between the old and new UIs, then being told about flakes but that they're experimental so it's not clear whether you should or should not use them.
I just went to the nix website, clicked "first steps with nix" and I get https://nixos.org/guides/ad-hoc-developer-environments.html
Is that useful? I'm sure to somebody who already knows what they want out of nix it is, but the first thing I'm told is that shell environments exist and are useful to "use the tool without having to install the software.". Ok, but what if I want to install the software? Then there's listing of what's essentially a magical invocation out of nowhere:
$ nix-shell -p 'python38.withPackages (packages: [ packages.django ])'
> We create an ad hoc environment with $PYTHONPATH set and python available, along with the django package.
thank you very much, that confirms I'd about interpreted the line correctly, but you've not told me what `withPackages` is or where `packages.django` comes out of so I'm not really helped.
And apparently the next step is "declarative and reproducible developer environments", or possibly "towards reproducibility: pinning Nixpkgs"? Or even better, "To quickly setup a Nix project read through Getting started Nix template", I have no clue what a nix project is or why I'd want one.
There's not just a step missing here, there's an entire floor, possibly building. It's like the nix community saw how git is taught and went "we can do worse".
Why would you go to https://nixos.org/learn.html, click on an introductory example titled "Ad-hoc developer environments" and complain that it doesn't explain how to permanently install software?
> but there's no real explanation to give me knowledge to expand upon
Again, you're pointing to a page containing TLDR examples. That's not the right place for an in-depth explanation.
> There's not just a step missing here, there's an entire floor, possibly building. It's like the nix community saw how git is taught and went "we can do worse".
No surprise because you missed the entire manual.
Because it's also the one labelled "First Steps with Nix". As in, the big orange button which immediately follows "Install Nix", and the second thing the Nix community apparently wants me to do to learn nix.
I literally did three things: I opened the nix website, I clicked "learn" (it's also what you get when you click "getting started" from the front page by the way), assumed I'd installed nix (I did check if there was seemingly critical information there, there isn't) then I clicked the following step.
I'm not quite sure what you'd want me to do.
> Again, you're pointing to a page containing TLDR examples. That's not the right place for an in-depth explanation.
I'm not asking for an in-depth explanation, I'm asking for pointers to the surface basics. The page tells me that "we’ll cover that in later tutorials" but I've no idea where those are, and none of the 5 links listed in the "next steps" seems helpful in any way. The least unpromising one ("Nix language basics") certainly didn't tell me anything about python.withPackages.
And again it's not "a page containing TLDR examples", it's what the website told me to start with.
> No surprise because you missed the entire manual.
The manuals which are at the bottom of the page (so one would assume the things to check after the one at the top of the page)?
And which are if anything even worse? The first one ("Nix Manual") goes directly from "you can upgrade packages" and "nix lets you rollback profiles" to "the nix language" to "advanced topics: remote builds".
I still have no answer to any of my question, but now I know that I can configure how many cores Nix will use when it builds derivations.
I still don't know what a nix project is or why I would want one, why I would want a derivation, though the manual does tell me they're important (why?)
> And again it's not "a page containing TLDR examples", it's what the website told me to start with.
So the website recommended you to read a page containing introductory examples. Not sure why you insist otherwise.
> And which are if anything even worse? The first one ("Nix Manual") goes directly from "you can upgrade packages" and "nix lets you rollback profiles" to "the nix language" to "advanced topics: remote builds".
What? The there are far more chapters in the Nix manual than just the three you mentioned.
Because if I don't know nix (which, you know, would be why I'd be reading introductory material) I'd be looking to use it, and my basis would be to do would be the way every other distro works.
And if I have to type `nix-shell -p python38` every time I want to run Python and `nix-shell -p vimMinimal` every time I want to edit a file, the experiment is not going to last long.
> So the website recommended you to read a page containing introductory examples. Not sure why you insist otherwise.
I'm not "insisting otherwise", I'm observing that it's confusing, utterly useless, and provides no real guidance towards improvement. And it's where the site told me to go as my second step into nix.
But apparently you're perfectly happy that this is what the "first steps with nix" should be (after having berated me for going there), so... proving the point I guess.
> What? The there are far more chapters in the Nix manual than just the three you mentioned.
Have you actually looked at them? ever?
1 is a quick overview of the entire thing, none of it actually helpful.
2 is a few basic commands expanded upon in (4)
3 is a lot of time spent on installation details
4 is where the meat starts, "You can upgrade package" is 4.1, "profiles are a thing" is 4.2, 4.3 is "nix will eat your disk space" (useless to a beginner), 4.4 is "channels" (even worse), 4.5 is "sharing packages between machines" which could not be less useful at this point./
5 is, as I said, "the nix language" covering the basics, with 5.4 mentioning derivations and going into plenty of details, none of them actually useful or telling a beginner why they should care
Following which we reach 6.1 "remote builds.
From a beginner's perspective, tits on a bull are at least funny, the nix manual doesn't even have that going for it.
Have a nice day, I'm done wasting time on you.
> after having berated me
Wow, I must be a terrible person, except I never recall berating you. I double checked, and it's just me expressing my disagreement. I'm not the one saying things like "It's like the nix community saw how git is taught and went 'we can do worse'" or "I'm done wasting time on you."
> Because if I don't know nix (which, you know, would be why I'd be reading introductory material) I'd be looking to use it, and my basis would be to do would be the way every other distro works.
Nix isn't a drop-in replacement of apt or yum. It's possible to use it like one, but that would be missing the whole point. Most of the benefits of Nix is obtained by writing configuration files tailored for each project you're working on. That's another reason why the examples don't start off with a replacement of "sudo apt install". Creating localized development environments is one of the primary use cases of Nix.
> Have you actually looked at them? ever?
Of course I did. I read the entire manual when I learned Nix. That's why I get the impression that your summary of the Nix manual makes it look more distorted than it actually is.
For example:
> 1 is a quick overview of the entire thing, none of it actually helpful.
The said overview includes instructions for installing packages permanently. You clearly stated that is what you were most interested in, so it actually should've been helpful for you.
Nope, it's a language, and thinking of it as those things, even more so firstly is probably part of the struggle.
It's a language that you use to get your computer to do specific things. In this case, it might be a "package manager" and in the other case it could be a "distribution".
When you write go or rust to print "hello world" to the terminal you don't go around and call these things "printers", or "hello worlders".
It's a language, just like rust, go, php, bash, ed, awk, and brainfuck. Your first example even shows you using the language why proclaiming ahah! shell thing, or package manger! -> `'python38.withPackages (packages: [ packages.django ])'` is using this language to instruct the computer to do something. If you don't want to take the time to learn the language and understand its outputs, and want to just think "this is a package manager" then you are going to get lost.
That is the exact reverse of the relationship between Nix and Nix.
When I write in Go or Rust, a printer is a tool I might use to achieve a specific sub-part of my over-arching goal.
My goal is not writing nix programs, I've got better programming languages available for that. Nor are the nix OS or package managers utilities of nix. The relationship is the opposite: the nix language is a tool provided to manage software or distribution in order to actually do things.
> Your first example even shows you using the language why proclaiming ahah! shell thing, or package manger!
Aha yes, that well known language of whatever apt is, checkmate!
> If you don't want to take the time to learn the language
I don't even mind that, I'm pointing out that the official nix documentation I got from the official nix site following its own recommendation gave me something utterly unhelpful which neither helps me in furtherance of my goals, nor provide any obvious steps towards that.
Having learned that `python38.withPackages` is a function called with an other function `packages: [packages.django]` as parameter does not help me either.
> want to just think "this is a package manager" then you are going to get lost.
I guess I should remove nix then, since it's not a package manager and that's what I'm looking for?
You should maybe think of fixing the branding by the way, because some folks slander nix by calling it an OS, and there's pages talking about "nix: the package manager".
In fact that's literally the tagline of the primary manual:
> Nix Manual: Nix is a package manager which comes in a form of many command line tools.
> Introduction: Nix is a purely functional package manager.
That is your issue. This is a language to write "operating systems" and "packages" it is not really a "package manager".
You use different programs and libraries to work with different systems.
>I guess I should remove nix then, since it's not a package manager and that's what I'm looking for?
Yes, I think that is the flaw, it's a language, that lets you write code that produces an output.
What surprises me is that people tout RPM/Chef as easier replacements to Nix/NixOS. The assumption about those being "replacements" of each other is questionable because they address different needs. What's even more questionable is the part about RPM or Chef being easy. I have dealt with those two for years as part of my day job, and they're both far from easy. I still have troubles with them to this day. Documentation is far more lacking than Nix, and it's not because things are obvious. If you encounter any trouble, you almost always have to dive into the source code. Navigating the source code of RPM or Chef is a nightmare because the code is scattered across countless different repositories and it's impossible to guess where to look for to begin with. Choice of programming languages doen't help here too. Chef is written in Ruby, which has a tendency of making code ungreppable due to its metaprogramming features. RPM has its own macro syntax which works similar to the C preprocessor. It's very terse and full of gotchas. Navigating around Nix code is much, much easier in comparison. Everything you need is in a single repo, https://github.com/NixOS/nixpkgs, and written in a JSON-like language.
Many people also claim that Nix is hard because it requires a functional programming background. That too doesn't match my experience. Nix expressions are basically JSON with functions. Learning the syntax is a non-issue if you know JSON and some common programming language constructs like conditionals, functions, map, filter and reduce. The only functional programming exposure I had prior to Nix was LISP, in a university classroom. Yet I didn't experience problems learning the syntax. The hard part is learning how to actually utilize the language. The documentation and some grepping around of the Nixpkgs codebase helped a lot with this.
One document tells you to flakes, another tells you that it’s experimental and should be avoided.
One document tells you that you should use Darwin modules and home manager, and then completely omits the fact that the linked home manager scripts don’t work with Darwin by design leading to “why the fuck isn’t this file they tell me should be auto generated not being created”.
Because the official docs don’t seem to cover real world use cases, you end up relying on a labyrinth of out of date and conflicting user contributed tutorials and it is very frustrating.
Once you know what to do nix is simple enough, but learning what to do is outright painful; if you don’t believe me look to the other replies to my comment.
At some point, I might try again, using NonGuix ( https://gitlab.com/nonguix/nonguix ), but right now I'm not using Guix SD. Instead, I try to use Guix on small projects (like building websites using pelican), without going full Guix.
What I'm most impressed with Guix is the time machine and Software Heritage integration, but it still needs a lot of improvement for developers, for example allowing to specify environment variables in manifest.scm files.
There is already .envrc or .dir-locals.el? And manifest is just - well - manifest. By definition it has to be 'plain'. I mean, there are already a million ways to load env vars so why'd you want guix to do that too and from manifest.scm of all places?
To me, that's not ok from an user experience point of view.
nix develop -c jekyll build
Or, for an automatic setup,
cat > .envrc
use flake
^D
cat > .envrc
if ! has nix_direnv_version || ! nix_direnv_version 2.2.0; then
source_url "https://raw.githubusercontent.com/nix-community/nix-direnv/2.2.0/direnvrc" "sha256-5EwyKnkJNQeXrRkYbwwRBcXbibosCJqyIUuz9Xq+LRc="
fi
use flake
^D
[1] https://github.com/nix-community/nix-direnv#direnv-source_ur...
(setenv "MAMA" "MIA")
(specifications->manifest (list "hello"))Any idea if nonguix will allow an install on macOS? I really want a system like this that I can use on my work MacBook and remote Linux servers.
Just use setenv in the manifest:
(setenv "MAMA" "MIA") (specifications->manifest (list "hello"))
Then `guix shell -m this-file.scm` enters a shell session where "hello" exists and the env var MAMA is set to "MIA".
I think the problem is that nix is just hard to learn. It's really different from most package managers, but people expect to look at a few examples and just pick it up intuitively. It's a whole different paradigm, with a custom programming language that also has a different paradigm. (Though Haskell folks eat it right up... no surprise there.)
It's gonna take time and effort to learn it, and there's just no way around it.
If it does, it's really well hidden. Because the nix manual certainly is not that.
> I think the problem is that nix is just hard to learn.
No, the problem is that nix offers no guidance or real help along that path. You go to https://nixos.org/learn.html and you've got essentially nothing helpful beyond the installation (which is easy enough). And it gets really bad when you get there from https://nixos.org/explore.html with no prior knowledge.
> Though Haskell folks eat it right up... no surprise there.
They're used to having to power through absent documentation?
This is either a misunderstanding or misrepresentation of the issue. We don't refuse to support Macs. Consider this:
- the value of Guix is in building up a package graph all the way from the very bottom (a tiny binary seed without parallel in other distros); this uses glibc. - glibc doesn't support Darwin - the only way to build software on a mac is to sign an EULA and use proprietary software (Xcode and the SDK).
It's easier to build software for Windows than for a Mac. If it was about "full hardcore FOSS" (what a weirdly judgmental term!) then we wouldn't support building for WSL or cross-compilation to mingw64, but we do.
Personally, I have no interest in working my ass off to get a subpar implementation of the package graph grafted on top of a huge binary blob (Xcode and the SDK) just to elevate a highly restrictive proprietary platform.
Until Apple commissions this kind of work it is still preferable to just use Guix in a virtualized GNU system.
This is the attitude I’m referring to when I say “hardcore FOSS”. You can choose to see it as a judgement if you want, but I view it as an implementation detail precluding my use of Guix.
“It’s hard and it’s not worth my time” is totally fine, I don’t expect projects to cater to my needs; but it’s worth calling out that it really seems like your chief complaint is that Apple is not FOSS (aka: proprietary).
Trying to learn /how to use/ nix was awful. I found lots of guides, almost always incomplete, and oftentimes directly contradicting each other. It took me weeks to get a working build and much of that time was anything but fun.
I like the outcome, and I’m glad I took the time now, but it was a slog that I don’t think I could really recommend to any of my peers.
It’s too bad guix went full hardcore FOSS and refuses to support macs, because they seem to have better docs and using a language that I can use outside of my package manager makes a lot more sense to me.