Of course this is a whole env thing and not just a package thing but I dunno I'd almost rather build a container and work within that than write nix to get this functionality, the ergonomics of teh language are that galling for me.
Started using nix this year, language is easy to use. Has very few concepts and syntax, it’s a standard functional language with all those goodies and a clean syntax in my opinion.
The language is fine, especially compared with its alternatives (e.g. templated yaml, yuck).
It's fairly straightforward to use. Running `devenv init` and then looking at the devenv.nix file should be all you need to know what to do.
Package names can be found by `devenv search $name`.
If you're happy writing shell commands/scripts, then just stick them in the following template:
with import <nixpkgs> {};
runCommand "name-of-your-thing"
{
someEnvVar = "some value";
someOtherEnvVar = "some other value";
buildInputs = [ programs you want to run ]; # e.g. see search.nixos.org/packages
}
''
run any bash code you like here
just make sure the file/folder you want to output
uses the env var "$out" as its path
''I don't think it's a good idea to defunctionalise the Nix language itself, since the result would either be too inflexibile or incredibly complex. Keep in mind that the Nix language has no idea what a shell is, or any concept of "package", etc. yet it's flexible enough to write functions like `runCommand`, which is used in the example above.
Also, it's reasonable to argue that Nix is already declarative, since that's what the `.drv` files are for! However, they're so tedious to work with that it's preferable to generate them using a "proper" language like the Nix expression language (or Guile Scheme if you're using Guix)!
(See http://www.chriswarbo.net/projects/nixos/bottom_up.html for a more in-depth explanation of .drv files, and how they relate to the Nix expression language)
The Nix language is designed by people that think everyone is familiar with lambda calculus and function programming. That's fine. But it's crazy to use a language like that for something that everyone has to use.
I bet Nix would be way more popular if it used something like Starlark instead.
I'll keep trying to give Nix and the language more work on my end.
I wholeheartedly disagree. Nix's `a -> b` is just a boolean function, like `&&`, `||`, `==`, etc. It's meant for assertions, e.g.
assert format == "csv" -> depth data == 2;
assert(depth(data) == 2 if format == "csv" else True)
> The Nix language is designed by people that think everyone is familiar with lambda calculus and function programming. That's fine. But it's crazy to use a language like that for something that everyone has to use.
The Nix language is basically just "JSON with functions" (although the syntax is unfortunately different, since JSON wasn't so popular back around 2003; it does support XML though!). There's only an emphasis placed on functions since they're the USP of the language; otherwise we could just use plain JSON. Lambda calculus is just a simple model of functions; you don't need to know or care about it in order to write functions in the Nix language. In the same way that you can write integer arithmetic in Nix without knowing Peano's axioms, or von Neumann's set encoding of ordinals, or whatever.
I've not used Starlark, but it seems to be waaaay more complicated than "JSON with functions"; e.g. it has loops, which makes the semantics dependent on some notion of time/temporal-ordering, which is sounds like a massive headache.
Trying to use a container to accomplish the same thing is not a substitute. They are fundamentally different.
How are you meant to install a piece of software and keep it up to date?
Is it a channel or flake? Are flakes stable or only for testing? So what's homemanager for?
Good luck getting answers on those questions other than "read the source code" and then followed by "no, not that source code, this branch here".
I really like the idea of Nix, but the communities priorities leave a lot to be desired of.
I usually recommend this guide for newcomers to Nix: https://zero-to-nix.com/
I don’t think there’s a beginner-friendly guide to NixOS. I personally learned it (and continue to!) through a number of blog posts and examples on Github. The NixOS manual is a key reference to rely on, but not really a tutorial: https://nixos.org/manual/nixos/stable/
Channel = group of named deps. 'Traditional' nix tracks a channel so when you update it, anything pointed to it also updates.
Home Manager = NixOS lite. Good option to define your preferred environment deterministically if you like another OS.
I experienced a similar situation last week with git-hooks.nix[1], a pre-commit integration for Nix.
I wanted to run biome[2] checks on my repository during pre-push so I wrote a custom hook because git-hooks.nix has pre-defined integrations with prettier and rome, but not biome.
Or that's what I thought. I eventually found out that the rome hook is actually referred as "rome" everywhere but calls biome instead[3]. This wasn't documented anywhere, so I opened an issue[4] suggesting to rename the hook to "biome" and keep the former for backwards compatibility reasons.
As of today, this has been acknowledged by one of the maintainers, whose sole feedback has been to "thumb down" the issue.
TL;DR: It's not just the documentation, but also the code not doing what you would expect. It also seems there's no means to improve the situation other than just forking the project since there's also clearly some kind of communication problem.
[1] https://github.com/cachix/git-hooks.nix [2] https://biomejs.dev/ [3] https://github.com/cachix/git-hooks.nix/blob/40e6053ecb65fcb... [4] https://github.com/cachix/git-hooks.nix/issues/428
I've not seen such hilariously bad communication since trying to talk to my thesis advisor.
Guix might use a scheme, but at least it has good documentation and seems more open to accepting contributions.
Looks like the OP, domenkozar, is that maintainer. Perhaps they'll reply to this thread :)