Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

NixOS 21.05

nixos.org

Post reply on HN
Print view View original

201–210 of 234 posts

Re: NixOS 21.05

#201

Post by kaba0 »

earksiinni wrote: post #185
kaba0 wrote: post #129

Earlier quoted context omitted.

> never appreciated how much package management is intertwined with individual ecosystems' cultures until I tried using a "universal" package manager like Nix. Unfortunately it is not a problem for nix to solve, they can’t really mandate upstream projects to not include hardcoded executables. Also, the problem with npm/pip etc is that they are themselves package managers more or less trying to solve the same thing. S…

> Unfortunately it is not a problem for nix to solve, they can’t really mandate upstream projects to not include hardcoded executables. Yet it's normal for Linux distros to patch upstream so that it works well inside of the distro. You may say "but that's crazy! Downstream patching Node packages opens up a whole can of worms!" Maybe you would be right--or maybe not. My point is that when I would raise these kinds of…

Thanks for expanding on it!

I feel the all-platform abstraction would be very difficult and leaky but at least some minor convention would indeed be great. Though I’m not sure how perfect the nix language is for very high-level abstractions —- I think the documentation problem is also in part due to not having static types.

Re: NixOS 21.05

#202

Post by lloeki »

bemeurer wrote: post #88
lloeki wrote: post #62

Earlier quoted context omitted.

> how painful was it to learn and get working? nixpkgs (which you can use on macOS or any Linux distro), quite little, you can get up to speed in 15min as a Homebrew replacement: nix-env -qas ruby # 'q'uery 'a'vailable 'search' nix-env -I ruby. # install by package name (not recommended) nix-env -iA nixpkgs.ruby_3_0 # install by "attribute", recommended nix-env -q # 'q'uery (i.e list installed) nix-env -e ruby # unin…

Please don't recommend that people use nix-env. It's one of Nix's biggest footguns and a huge support burden for the maintainers. We've been actively trying to remove mentions of it from the documentation. If you want something "installed" use home-manager. If you just want something for quick dev use nix-shell.

> If you want something "installed" use home-manager.

I hear you. I understand nix-env as it exists needs to go, and I can only trust you on the support side. I did not know about home-manager.

Doing my homework, from home-manager README, I can read:

> Before attempting to use Home Manager please read the warning below.

> Unfortunately, it is quite possible to get difficult to understand errors when working with Home Manager, such as infinite loops with no clear source reference. You should therefore be comfortable using the Nix language and the various tools in the Nix ecosystem.

> Home Manager targets NixOS unstable and NixOS version 20.09 (the current stable version), it may or may not work on other Linux distributions and NixOS versions.

> Also, the home-manager tool does not explicitly support rollbacks at the moment so if your home directory gets messed up you'll have to fix it yourself.

On top of being third party (for now?), all of this really does not bode confidence in the tool and severely raises the bar for adoption when all one wants is to install tmux globally for their user (IOW a bunch of symlinks in ~/.nix-profile/bin that "just works").

But the best one is this in the manual:

> This manual will eventually describes how to install, use, and extend Home Manager.

There is no section in the manual describing the usage of the tool. The Getting Started seems to be solely about development and contributing. The terse examples in the README is what made me search for the manual, and I could only get a grasp of what they entail because I have NixOS experience. Seriously, if this is deemed "general public availability" quality, this is borderline user hostile.

So, I do note the envisioned deprecated-ness of nix-env but I will continue to use that as a first rung to help people climb the ladder when I introduce people to nix until there is a suitably accessible and reliable replacement.

Indeed I successfully used it as a beachhead for people to eventually jump ship:

"see? It's easy to install and use, you'll be quite autonomous. And if you feel it's not your thing just ignore it or rm -rf /nix"

Then I bait them with e.g shell.nix (which feels like Gemfile) or nix-shell -p --run (which feels like docker run) just enough to make it relatable while teasing their curiosity.

So instead of feeling overwhelmed by a whole new arch complete with a foreign config system and an alien language, and contractually tied by configs they feel confident, uncommitted, free, empowered, and curious, and that much more likely to transition to the next rung up.

> If you just want something for quick dev use nix-shell.

That I 100% agree with, which is why I immediately described it as well. It's the hook to the next rung.

> In some cases Home Manager cannot detect whether it will overwrite a previous manual configuration.

That, to me, is a problem. I fully acknowledge the limitations and caveats of nix-env, and duly highlight them when introducing people to nix, but this means home-manager is not the tool I need, in git parlance it's way too much "porcelain" and not enough "plumbing". It feels invasive when you're still in the process of getting acquainted.

I do not want home-manager to handle launchd, nor .gitconfig. I do not use nix-darwin or NixOS, _on purpose_, as I use nixpkgs as an additional tool, an extension of existing systems.

I am fine if nix-env has some of its features revamped, or is deprecated and replaced by a better tool but in terms of some of its existing use cases it is exactly the tool needed, i.e merely allow users or root to make a package persistent and widely available for the user or for root in their PATH, as if it were a native package, and with no other side effects.

I hope you understand these are legitimate needs.

Re: NixOS 21.05

#203

Post by takeda »

lpmay wrote: post #186
rkangel wrote: post #68

Earlier quoted context omitted.

I use nix-shell for dev environments. Once I've got it working it's wonderful - full replicable, across multiple development machines and CI. It's painful though. Some problems I've encountered recently on different projects: Old version of fwup packaged. Can override to get newer version, but needed to add another dependency to make tests pass (and it gets built locally rather than being cached) Pain getting my envi…

Just a hint - extra attributes in the `mkShell` appear as environment variables in the built shell. So instead of a `shellHook` for this you can just have an attribute `ERL_LIBS="";` I'm not completely sure but I think this approach is preferred because shellHook only runs in `nix-shell` but if you ever wanted to `nix-build` a release it might not run.

There tools like direnv, that "enter" your env environment as soon as you cd to the directory. This is implemented by changing environment variables like PATH.

Because shellHook allows on executing any code, there's no standardized way to undo what it executes, so those tools don't execute that part.

Re: NixOS 21.05

#204

Post by aitchnyu »

kovek wrote: post #38

How is managing python packages or ruby gems on NixOS? I remember the experience was not polished a few years ago.

I see isolated dev environments in terminal. Can Pycharm (IDE and GUI) pick up these environments?

Services and dev tools want to hog system ports. Can I run multiple dev projects each managing own services in Pycharm?

Re: NixOS 21.05

#205

Post by squiggleblaz »

kaba0 wrote: post #129
earksiinni wrote: post #96

Ahhhh, Nix/NixOS. The package manager/OS that I so desperately wanted to love. I stuck with Nix for about six months. I even became a package maintainer. In the end, I gave up for three reasons: 1. Documentation is really bad. It's often confusing, incomplete or just plain wrong. What drove me crazy is the extreme imprecision with which certain fundamental concepts are referred to. For example, "derivations" are amon…

> never appreciated how much package management is intertwined with individual ecosystems' cultures until I tried using a "universal" package manager like Nix. Unfortunately it is not a problem for nix to solve, they can’t really mandate upstream projects to not include hardcoded executables. Also, the problem with npm/pip etc is that they are themselves package managers more or less trying to solve the same thing. S…

>Also, the problem with npm/pip etc is that they are themselves package managers more or less trying to solve the same thing.

The problem is that they're trying to solve different problems. NPM/pip etc are mostly about letting the developer of an internal application choose and acquire dependencies for their project. Nixpkgs/dpkg etc are about letting the developers of a system acquire and maintain dependencies for a whole system.

These two goals pull in different directions.

NPM/pip want to have available every released version of every package, so that when I can keep using legacy-package with a well-tested version of web-dependency. This way, I can focus my attention on the important matters of writing new code for contemporary-project. I can be confident that legacy-package will keep running the same way it used to, security bugs and all, until I make a decision to attend to it.

Nixpkgs/dpkg want to have available as many packages as possible with a target that every api incompatible library is included, so that any two programs which use the same api use the same version of a package. This way, if they need to patch a well-tested but insecure version of web-dependency, all programs which use it will be kept up-to-date.

Because nix is an agnostic build tool, it can run in both modes simultaneously. You can create a nix expression that uses nixpkgs to build a system that provides a runtime environment and a system that provides a buildtime environment and then uses internal project dependency managers to fulfil the lockfile and installs the product of that, node_modules and all, onto the runtime system. You will lose certain guarantees by doing it this way, and perhaps some parts will require awkward, but that is an engineering decision. For instance, nix won't be able to verify that you aren't depending on changeable remote systems, because you'll have chosen to do that: Nix doesn't trust that npm is add-only, but you might. (Also, some aspects of this will be poorly documented. That's a fixable problem, but the maintainers of a package distribution are probably less interested in the case that optimises for concerns they've chosen not to optimise for, so the documentation for working that way will naturally be worse.)

Re: NixOS 21.05

#206

Post by Ambroisie »

adkadskhj wrote: post #165
kaba0 wrote: post #154

Earlier quoted context omitted.

I don’t really understand your problem as in NixOS it is precisely the easiest to handle some packages from this repo and anothers from another. You can just add a single line of an alternative repo like altNixpkgs = “reference repo either by url or path” in the let in “block” and instead of pkgs.something just use altNixpkgs.pkgs.something. Also, I usually manage my home packages separately from my global config. Th…

> I don’t really understand your problem as in NixOS it is precisely the easiest to handle some packages from this repo and anothers from another. You can just add a single line of an alternative repo like altNixpkgs = “reference repo either by url or path” in the let in “block” and instead of pkgs.something just use altNixpkgs.pkgs.something. Yea, i actually do that for a couple of my dependencies. My problem is the…

You can use the Nix tooling to show the diff between two derivations' closure.

I have a script which I use [1] after updating my Flakes to do just that : know what has been upgraded.

[1] https://github.com/nix-community/nur-combined/tree/master/re...

Re: NixOS 21.05

#207

Post by scns »

nitsky wrote: post #65
rkangel wrote: post #19

Earlier quoted context omitted.

Honestly - how painful was it to learn and get working? And what limitations/niggles are left when using as a workstation? I love the principles behind Nix, and I like to use it to provide development environments (through nix-shell locally and then using the same setup in CI). But some things can be moderately painful to get going.

Using NixOS with flakes is actually quite simple once you already know how to do it, but the lack of high quality tutorials made it difficult for me to get started. I hope the community will improve this situation over time.

Could you write one?

Re: NixOS 21.05

#208

Post by pimeys »

kaba0 wrote: post #145
sorbits wrote: post #139

Earlier quoted context omitted.

> and a few servers The problem I see with NixOS on a typical personal server is that you have to setup all these things using nix expressions, from which the actual configuration files are generated. That means if you e.g. want to install postfix, instead of learning about main.cf you have to learn the syntax of the nix configuration wrapper for postfix, and postfix having hundreds if not thousands of options, many…

Your best friend is https://search.nixos.org/options From a quick search, it seems you can use `services.postfix.config` and pass key-value pairs as arbitrary options. Not familiar with this service, but usually if a given one has more complex syntax, there is a “pass-through” option that will simply append to the given config file whatever text you provide, as well as as the sister reply says you can create manually…

Even better: `man configuration.nix` and `man home-configuration.nix`. I used the website first, but found out just using the quite good man pages is much much faster.

Re: NixOS 21.05

#209

Post by pimeys »

kaba0 wrote: post #124
pimeys wrote: post #83

Earlier quoted context omitted.

I fork the repo, update the package in my fork, add the fork as a flake to my inputs and test my changes. When I'm happy, I create a pull request to the main repo. I started using NixOS in all my machines last winter, and slowly decided it is for me when I understood the basics. It was a rough start for me, but I have a few decades of linux knowledge, that helped me past the starting point. You can read my config and…

I would just add that more often than not it is as easy as changing the version string in the somePackage/default.nix file and changing the corresponding hash of the source. Of course if the build changes in the new version or it depends on some new lib it can become a bit more difficult, but with a bit of experience it is not that hard to solve.

And to get the hash of some file you download, you can do `nix-prefetch-url https://us.download.nvidia.com/XFree86/Linux-x86_64/460.80/N...` that'll cache the file for you and give the sha256. Remember to add `--unpack` if the file is an archive.

Re: NixOS 21.05

#210

Post by Blikkentrekker »

Nullabillity wrote: post #42
Blikkentrekker wrote: post #34

Earlier quoted context omitted.

Almost any system can do that. Package managers typically have a concept of a “selected set” or something o that nature which is often simply a file that contains all the packages the user wants to install on a new line at some places. Simply copy that file and do a world update with the package manager and it will install all those packages an their dependencies and typically uninstall what is not needed.

NixOS also covers package configuration, not just which packages are installed. And because it owns all of the configuration, it can semi-intelligently merge package configurations that are managed in multiple independent places. It can also be used to apply patches to packages (which are then automatically carried over when the upstream package is updated).

> NixOS also covers package configuration, not just which packages are installed. And because it owns all of the configuration, it can semi-intelligently merge package configurations that are managed in multiple independent places.

Do you mean system configuration in /etc, or also user configuration in /home?

In the latter case I do not see how this can ever be implemented, even if an exhaustive list be provided with each package in it's description, quite a bit of software will arbitrarily add new files under new names as part of it's confguration.

Usually one simply copies one's entire `~/.config` directory along.

> It can also be used to apply patches to packages (which are then automatically carried over when the upstream package is updated).

True, but this is also a feature of any source-based system.

The real advantage to me seems to be that it is a source-based system but with a central repository for identically configured packages to avoid compilation in many cases.

Post reply on HN