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

We want to make Nix better

determinate.systems

Post reply on HN
Print view View original

141–150 of 204 posts

Re: We want to make Nix better

#141

Post by rgoulter »

zuzuleinen wrote: post #60
yewenjie wrote: post #43

Earlier quoted context omitted.

How does Bob handle network requirements (downloading dependencies during the build)? I think that is one of the biggest pain points for nix packaing. Many projects have build instructions that depend on downloading stuff in a complex manner that cannot be easily abstracted/shaped to what Nix expects.

I wrote a short guide[1] how bob uses Nix, but essentially we still use `nix-build` under the hood to build a list of packages you give under dependencies > Many projects have build instructions that depend on downloading stuff in a complex manner that cannot be easily abstracted/shaped to what Nix expects. Are you referring here to packages which are not available in Nixpkgs? [1] https://bob.build/docs/usage/package…

The point is: a couple of the tough points in packaging something with Nix are "how to come up with the Nix expression", but also how to get the software you're packaging to build with the constraints Nix has (no fetching external dependencies, shared libraries explicitly declared in non-standard locations, etc.).

A bespoke YAML format is arguably not simpler than just "here's the equivalent Nix expression". But, sure, can be more accessible for some people.

But, providing a nice facade over the Nix language doesn't help with cases of where Nix can be difficult to work with.

Re: We want to make Nix better

#142

Post by Bolkan »

mamcx wrote: post #84
grhmc wrote: post #2

With Eelco as a cofounder of DetSys, I feel really excited about where we're going here. I think the world is in many ways primed and ready for Nix, as long as we can help Nix "meet them in the middle." We're working on making Nix more accessible and producing good and usable, production-ready workflows so teams can just pick it up and go. I'd love to hear what y'all think, to help make sure we're going in the right…

My main gripe is documentation. Look at this: https://nixos.wiki/wiki/PostgreSQL Now, the real "workflow" with nix is look at other setups, or just look at the code: https://github.com/NixOS/nixpkgs/blob/master/nixos/modules/s... And look at the code is the only reliable way to see what exactly is supported. My second gripe is the fact is hard to see what nix do. Today I hit this trouble: https://www.reddit.com/r/Nix…

Yeah, dealing with user directory is a pain, and it is a pain because you can't make it completely functional (what about passwords). And it is the only place I found where nix doesn't work as you would expect it to in my 3 years of nixos use.

Re: We want to make Nix better

#143

Post by rgoulter »

ParetoOptimal wrote: post #71
yewenjie wrote: post #43

Earlier quoted context omitted.

How does Bob handle network requirements (downloading dependencies during the build)? I think that is one of the biggest pain points for nix packaing. Many projects have build instructions that depend on downloading stuff in a complex manner that cannot be easily abstracted/shaped to what Nix expects.

> Many projects have build instructions that depend on downloading stuff in a complex manner that cannot be easily abstracted/shaped to what Nix expects. The basic way to fix this with nix is: 1) download the thing with a fixed ouput derivation: a derivation who's source has the URL and checksum of the artifact 2) copy the artifact from the nix store where said build tool stores it

In nix expressions, sure; but bob uses YAML, and uses that to drive nix.

Re: We want to make Nix better

#144

Post by rssoconnor »

joshka wrote: post #131
rssoconnor wrote: post #61

Earlier quoted context omitted.

> To seriously answer the question: is the Nix language required for the Nix packaging system to exist? Laziness is required, to some degree, but can the next iteration provide an on-ramp which doesn't involve learning a new lang and paradigm? Guix folks sure think so. I'd love to hear from someone deeply familiar with Nix and Guix about laziness. I'm deeply familiar with Nix and I've concluded that lazy semantics is…

> Nix's system of overlays depends on laziness too to provide efficient late-binding familiar from OOP. As an OOPer, inheritance is one of the things that is generally trotted out as the worst aspect of OO languages. This leads to the mantra "favor composition over inheritance". Much has been written about why and how. But it seems to cause the same pain points that people talk about with respect to laziness in Nix.…

I actually agree with you about inheritance and OOP. It's funny because when I finally understood how to override packages with this late-binding technique, I said to myself "Finally I've found a use for inheritance!".

I certainly think people should exercise caution as this could probably be abused quite badly. Maybe people will come up with better designs in the future. However I will say, that the method it has replaced was much worse. The old way was adhoc and almost always failed to achieve ones desires in all but the simplest cases.

Don't just take my word for it. Peter Simons also agrees: https://github.com/NixOS/nixpkgs/commit/3c8b33eee442fd573d47...>

Re: We want to make Nix better

#145

Post by yamtaddle »

chrisseaton wrote: post #20
ParetoOptimal wrote: post #17

Earlier quoted context omitted.

OSX requires mounting root folders like /nix with synthetic.conf IIRC.

Right but the comment said they compromised on using a different directory in the end, so it could be under /opt like Homebrew, and not a root directory.

> it could be under /opt like Homebrew

You can install Homebrew other places, too, for that matter.

I'd only tried NixOS (bounced off, couldn't get X-Window working even following tutorials to the letter) not Nix on macOS. "Must be installed in a specific, root directory" is a hard no for me, when it comes to add-on package managers. That's one hell of an odor.

Re: We want to make Nix better

#146

Post by dd_ »

As someone who has been using NixOS for a couple of years now, I really want to say how appreciative I am of everybody for making noticeable improvements to the system on a somewhat regular basis. The nix command keeps on adding great new features like flake templates and bundling as well as just being more user friendly (error messages, actionable hints, etc.) Additionally, tools like nix-ld [1] make nix more usable than ever with software from external sources. Things just keep on getting better for NixOS users!

Despite the reputation, I feel that NixOS or some derivative of it has the power to become the best distribution for non-technical users in the long run. What NixOS has done is effectively built an interface to every component of a modern Linux system, all that needs to be built is a user application to take advantage of it. Of course, there still needs be some improvements in Nix itself for it to blossom into its final form, but I really see a path to greatness here.

I have often thought about creating a simple unified Win2K-esq or BeOS-like X11 WM/DE specifically for NixOS but unfortunately I lack the time/motivation.

[1] https://github.com/Mic92/nix-ld

Re: We want to make Nix better

#147

Post by colordrops »

mamcx wrote: post #84
grhmc wrote: post #2

With Eelco as a cofounder of DetSys, I feel really excited about where we're going here. I think the world is in many ways primed and ready for Nix, as long as we can help Nix "meet them in the middle." We're working on making Nix more accessible and producing good and usable, production-ready workflows so teams can just pick it up and go. I'd love to hear what y'all think, to help make sure we're going in the right…

My main gripe is documentation. Look at this: https://nixos.wiki/wiki/PostgreSQL Now, the real "workflow" with nix is look at other setups, or just look at the code: https://github.com/NixOS/nixpkgs/blob/master/nixos/modules/s... And look at the code is the only reliable way to see what exactly is supported. My second gripe is the fact is hard to see what nix do. Today I hit this trouble: https://www.reddit.com/r/Nix…

I'm looking at your second link, and it's not really that bad if you are familiar with nix. It's a standard pattern for a package with options. Mostly a long enumerated list, not any different from a long enumerated list of the postgres options themselves. The great thing about it is that it's a single DSL, instead of 10,000 DSLs, one for each package you install.

I do think command line options to do what you ask would be nice, but in order to keep the declarative reprudicibility you get with nix, those commands would need to operate on nix config rather than the system itself. They could update the config then update the system based on the config, so it could look like one step even though it is two behind the scenes.

Re: We want to make Nix better

#148

Post by rgoulter »

skybrian wrote: post #120
ParetoOptimal wrote: post #74

Earlier quoted context omitted.

> The external dependency problem is somewhat solved in npm (at least, as far as many users are concerned) by writing a module that downloads the appropriate binary. This complicates working on node projects with nix in my experience. Is there a way to tell npm "no, just use my binary"? Best i've found is letting npm download it and then overwriting the npm binary with the nix one in a postinstall script. Why you ask…

If you know how to build the binary from scratch, could you teach the npm package's continuous build to do it? Sending a pull request fixing the npm package would fix it for everyone, not just nix users. Also, I wonder if nix would be a suitable tool for generating npm packages that contain binaries? Maybe this is a way for people to benefit from nix without actually using it.

> If you know how to build the binary from scratch, could you teach the npm package's continuous build to do it? Sending a pull request fixing the npm package would fix it for everyone, not just nix users.

The "I have a binary already, just use this one" is in response to the problems NixOS users face dealing with helpful software like this.

NixOS doesn't provide shared libraries in the standard locations (for good reasons). Binaries that tools like NPM download will link against shared libraries in the standard location.

It's not really a question of "providing the binaries would help", because it's about assumptions of where the shared libraries are.

Re: We want to make Nix better

#149

Post by mamcx »

colordrops wrote: post #147
mamcx wrote: post #84

Earlier quoted context omitted.

My main gripe is documentation. Look at this: https://nixos.wiki/wiki/PostgreSQL Now, the real "workflow" with nix is look at other setups, or just look at the code: https://github.com/NixOS/nixpkgs/blob/master/nixos/modules/s... And look at the code is the only reliable way to see what exactly is supported. My second gripe is the fact is hard to see what nix do. Today I hit this trouble: https://www.reddit.com/r/Nix…

I'm looking at your second link, and it's not really that bad if you are familiar with nix. It's a standard pattern for a package with options. Mostly a long enumerated list, not any different from a long enumerated list of the postgres options themselves. The great thing about it is that it's a single DSL, instead of 10,000 DSLs, one for each package you install. I do think command line options to do what you ask wo…

Yeah, I think "look at the code" is not that bad if is embraced, like the docs of Rust. But half-docs in wiki, then in another links with options, then in code not work, IMHO.

Re: We want to make Nix better

#150

Post by techdragon »

mook wrote: post #117
dial9-1 wrote: post #97

Earlier quoted context omitted.

flakes are anything but experimental at this point, they've been out for many years and I pretty much use them for everything. you don't have to type those flags if you add them to the configuration file

A newcomer is going to treat anything documented as experimental as that, regardless of what the community thinks; if it's no longer experimental, it needs to be presented as such at all the normal entry points. (None of this is unique to Nix; imagine you needed to start packaging for Windows for some reason.)

This is exactly what I mean. It’s a big put off to see several year old experimental features and other signs that no one is making the decision to move things forward.

If I’m learning something as big as nix with all the facets it has, I don’t also have time to learn it’s entire community history. It’s not a good thing that I need to do that in order to make a decision about how much to trust experimental features of a tool when I’ve not even been using it more than a few hours from the moment of downloading the iso and installing it. It’s a put off to someone new coming to use nix for the first time.

Post reply on HN