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

Nix as OS X Package Manager

ariya.ofilabs.com

Post reply on HN
Print view View original

161–170 of 209 posts

Re: Nix as OS X Package Manager

#161

Post by mikemcquaid »

ghshephard wrote: post #117
lilyball wrote: post #115

Earlier quoted context omitted.

Homebrew is not dangerous. Please don't spread FUD. Your link specifically covers the case of Homebrew on the server . But Homebrew isn't meant to be a server package manager. It's an OS X package manager, and OS X is a desktop operating system, not something that most people choose to use as a server (OS X Server exists but is primarily used for intranet stuff rather than as a production server). The complaints that…

Totally agreed. Homebrew is not an appropriate tool for server package management (It assumes everything should be installed under a single user account)- but 98-99%+ of the people that use OS X and servers are not running OS X on their servers, macmini colo users excepted. The wording dangerous was poorly used, inappropriate for server package management would have been better.

"inappropriate for server package management" is totally fair. That's why we try to generally default to only listening on localhost.

Re: Nix as OS X Package Manager

#162

Post by mikemcquaid »

jd3 wrote: post #60

Why use nix when pkg-src has been available on Darwin for over 15 years, boasts more packages, and has decades of support (plus Jonathan Perkin and the guys over at Joyent)? Why people assume the gross project known as homebrew (and the better macports, where homebrew gets all of their real package patches) are the only two package managers on OS X/Darwin is perplexing to me... Not to say nix is not interesting, but…

Homebrew and MacPorts users both patch upstream projects and share patches between projects.

Re: Nix as OS X Package Manager

#163

Post by vetinari »

cstrahan wrote: post #122
educar wrote: post #80

This sounds exactly like what homebrew does. It also installs under /usr/local and does not touch anything else. What does nix package manager provide that homebrew does not? (from a user point of view)

Hi, I'm a NixOS/Nixpkgs comitter and package maintainer for plenty of stuff -- including X11/XQuartz for OSX. Nope. They both do package management, but that's where the similarities end. Homebrew packages are not patched to point at precisely the version of the stuff they were built against. For example, if you have program that dynamically links to openssl, that program is built with the expectation that the dynami…

How do you solve unintended dependencies, that are in the path you have to include?

For example, when building postgresql on OSX, it always links against libpq.dylib in /usr/lib, not against the one it just built. In theory, it could be possible to exclude /usr/lib from the -L path, but then I would lose other libraries, that ship with the system (i.e. libz, libxml2, libxslt, libpam, libSystem). The other possibility is to build all these dependencies too - except libSystem...

Right now I'm using install_name_tool to fix the binary, but that is an ugly hack. (The other problem in this case is, that system libpq is x64-only. It means that i386 build would fail).

Re: Nix as OS X Package Manager

#164

Post by guitarbill »

cstrahan wrote: post #128
guitarbill wrote: post #96

Earlier quoted context omitted.

none, which is why this article is so vague. like i needed another folder in root, as if `/opt/`, `/usr/local/` or `~/.local/share` weren't good enough and this is somehow a feature. another package manager that has less features than homebrew? oh, like fink and macports - no thanks.

It would appear that your primary takeaway is that we put stuff in a different directory, for an apparently arbitrary reason. I agree, that would be silly -- if it were the case. With /usr/local/{bin,lib,include}, how would you install multiple versions of openssl? Would you violate convention and do something like /usr/local/openssl-x.x.x/{bin,lib,include}? How do you avoid file path conflicts? When a package is bui…

Thanks for the enlightened response to my rather curt post.

I guess my main issue with the original article was that if you don't already know what nix is, the benefit is not at all obvious, especially for the (above?) average joe for whom homebrew works fine. For a sysadmin who is sick of dependencies breaking, even when using something like aptitude, it sounds perfect though.

Although after skimming the nix docs [1] and reading your reply, I'm still not sure why e.g. `/opt/nix/` wouldn't work. Maybe it would, except for the fact that `/nix` was decided on and if you now change that, the prebuilt packages break (see [1])? Obviously, it isn't a deal-breaker, but e.g. consider an existing backup solution which might have been configured inclusive, not exclusive.

Also, I get that as a package manager, nix is in a different position than most programs, but putting stuff in `/` isn't a great precedent, and other package managers don't AFAIK.

[1] https://nixos.org/nix/manual/#ch-about-nix

Re: Nix as OS X Package Manager

#165

Post by mseri »

jperkin wrote: post #149
aorth wrote: post #144

Earlier quoted context omitted.

pkgsrc is great and I prefer it to Homebrew on Mac OS X, but it only updates quarterly. :(

Not true any longer, at least for the binary packages I produce[0]. I switched them over to trunk-based builds a while ago, which are updated every few days. [0] https://pkgsrc.joyent.com/install-on-osx/

How is situation with python3 on osx? Last time I used pkgin, it was not compiled as Framework preventing some libraries to work properly

Re: Nix as OS X Package Manager

#166

Post by geocar »

Singletoned wrote: post #160
geocar wrote: post #152

Earlier quoted context omitted.

> In my experience with software, sharing opaque binary blobs is a Bad Thing And yet you don't know why. This is called dogma, and dogma is bad: It leads people to make stupid decisions over and over, all the while repeating that the alternative is worse.

No, this is called learning from experience. If you put your hand in a fire 5 times and it burns you 5 times, you don't have to understand anything about fire to know that you should probably stop putting your hand in. And if you saw other people about to put their hand in, you would mention to them that everytime you put your hand in, you end up regretting it.

And yet, here I have asbestos gloves and I can put them in the fire just fine. This allows me to work faster and get done without waiting a day for the fire to run out of fuel.

We don't need religion to keep from getting burned when we have tools.

Re: Nix as OS X Package Manager

#167

Post by regularfry »

oconnore wrote: post #19
nickysielicki wrote: post #5

> curl https://nixos.org/nix/install | sh Stop doing this. Look, even if you are rolling your eyes and thinking, "it's https and I'm not Ed Snowden, I think I can afford the risk for the benefit of an easy install process", what happens if curl is interrupted? Are you excited at the prospect of a half-ran install script that you didn't even look at?

No [1]. If you are installing software from scratch, you must trust the https server that serves it to you. They could publish sha256 check sums to https://nixos.org/hashes , but you would have to trust the https server. They could publish their gpg key to https://nixos.org/gpg , but you would have to trust the https server. Things would be better if we had a reasonable certificate system for verifying open source so…

That's not the only thing you have to trust.

http://ariya.ofilabs.com/2016/05/nix-as-os-x-package-manager... is served over HTTP. Saying "Copy and paste this `curl | sh` command" allows this attack: http://thejh.net/misc/website-terminal-copy-paste

Re: Nix as OS X Package Manager

#168

Post by zimbatm »

nextos wrote: post #68
rdtsc wrote: post #15

When I first heard about Docker, I thought it did what Nix does. Then someone handed me a docker image saying, "I got this working on my laptop, deploy this. Isn't this great!". I had no idea how they arrived at that configuration. If something happened to them or that image, I wouldn't have known how to reproduce that "working state". So I am happy to see Nix / Guix become popular. It is what I imagined package mana…

Also people forget that the Nix philosophy doesn't end in the package manager Nix, there's also NixOS which takes a functional approach to configuration management of the whole OS. And many other things.

And nixops which allows you to build everything locally (or delegated to a build machine) and push configuration to multiple machines.

Re: Nix as OS X Package Manager

#169

Post by msiebuhr »

jb55 wrote: post #83
lfam wrote: post #50

Earlier quoted context omitted.

In Guix, we address this problem with grafting. Rather than rebuild everything that depends on the fixed glibc, we build the fixed glibc, then rewrite all references to the old glibc to refer to the new one. That rewriting happens in new copies of the referring packages, of course, since the "store" is immutable. https://www.gnu.org/software/guix/manual/html_node/Security-... https://savannah.gnu.org/forum/forum.php?…

Nix has a way of doing this as well, just needs a better UX (like most of nix).

I was quite surprised that `nix install vim` didn't work out of the box. More so after realising that there's not even a `nix` command.

I see that there's a bunch of `nix-whatever` tools around, but even their names aren't much sensible.

I'm not in doubt that nix is technically superior to homebrew, but UX-wise it's at least been a disappointing experience for me.

Re: Nix as OS X Package Manager

#170

Post by drdaeman »

hso1 wrote: post #59
drdaeman wrote: post #48

Earlier quoted context omitted.

By chance, do you have some public/sample projects that use this approach?

Yes! Look here: https://git.hso.rocks/hso/def Is a Telegram bot that queries the RAE dictionary (Spanish). It doesn't have any documentation yet, though :S You can look for the project deps code here: https://git.hso.rocks/hso

Looks great, thanks for sharing! I'd definitely try this approach.

Do you write default.nix files by hand, or there are some tools to automate the process?

I suppose for a project with a lot of dependencies (one of my current requirements.txt is over 100 SLOC long - almost all deps are on PyPI; haven't checked nixpkgs as I'm stuck with Debian at the moment) it would be somewhat tiresome to check every package and for every missing one list all the dependencies.

Post reply on HN