Live data from Hacker News

Nix solves the package manager ejection problem

zeroindexed.com

1–10 of 50 posts

Re: Nix solves the package manager ejection problem

#3
I think the issues with traditional packages all boil down to the fact that packages are not files. Packages are some transformed instance of some code, operating over a computer's resources in some way. Sure, eventually you get down to the fundamental file abstraction, but it can take a bit: all the variations of building from a single code base. What I like about Nix is that it stops representing packages as files and has its own declarative syntax. The OP observed what really is a side effect of that change, and it's great! Sometimes, though, I wish it went a bit farther than it does - there's room for a few more useful transformations between a package's code base, a package, and a file. If the nix program itself took a bit more control over the system, I think it would end up in a really cool place. The specifics of that, though, I do not know.

Re: Nix solves the package manager ejection problem

#6
That works for the kernel. But if you have to patch, say, glibc, under Nix doesn't that mean you can no longer use precompiled binaries, and have to recompile every single package that uses libc, from source?

Sure, it still works. And in the off-chance that you need to make a patch that changes the ABI, recompiling the world is exactly what you want. But usually you don't need to change the ABI (at least not in a backwards-incompatible way), and recompiling the world can take a very long time.

Re: Nix solves the package manager ejection problem

#7
post #6

That works for the kernel. But if you have to patch, say, glibc, under Nix doesn't that mean you can no longer use precompiled binaries, and have to recompile every single package that uses libc, from source? Sure, it still works. And in the off-chance that you need to make a patch that changes the ABI, recompiling the world is exactly what you want. But usually you don't need to change the ABI (at least not in a bac…

This may change in the future with Nix moving to a content addressable store.

I lack the technical know how behind it, but if the output of a package doesn't change on changing one of the inputs then nix will not rebuild it's cache.

Re: Nix solves the package manager ejection problem

#8

Read the NPM doc but I still don't understand what "ejection" is. What are we ejecting? Can someone explain this please?

My general understanding is that ejection means you are abandoning a state that can safely accept updates from the original source.

"You're on your own, buddy. Good luck!"

Re: Nix solves the package manager ejection problem

#9

Read the NPM doc but I still don't understand what "ejection" is. What are we ejecting? Can someone explain this please?

I believe the confusing bit is that it's not an NPM thing, it's a create-react-app thing. create-react-app is a helper tool for, as the name says, creating React applications and doing a bunch of things out of the box. Occasionally you reach the point where you need to do something more complex than create-react-app can handle for you. In that case, you run the "eject" script in the generated app (using "npm run" as the runner), which removes create-react-app's automatic build dependency from your project and sets it up as if you had put together all the pieces by hand. But create-react-app still works, for the most part.

(In this context, I think what is being "ejected" is the build dependency automatically added by create-react-app.)

I don't think it's a perfect analogy, but I see what the author is getting at - you need to break the abstraction of some packaging tool, but you want the functionality it provided to still work as well as possible.

Post reply on HN