Live data from Hacker News

Nix as OS X Package Manager

ariya.ofilabs.com

201–209 of 209 posts

Re: Nix as OS X Package Manager

#201
post #104

Earlier quoted context omitted.

You're not wrong, but Docker comes at it from a different angle; Docker expects you to be handing around tagged images, to solve a similar set (but not the same set!) of problems that reproducible builds solve. Ideally, I want _both_ of them: tagged Docker images being sent between environments (with `docker run -e SOME_ENV=testing imagename` for changing the internal config), but reproducible builds in my Dockerfile…

Yes, you can do this. There is a utility "nix-docker" that will convert a Nix configuration file into a BusyBox Docker image (see e.g. http://zef.me/blog/6049/nix-docker )

with nix you can now build docker images ... docs are in the manual http://nixos.org/nixpkgs/manual/#sec-pkgs-dockerTools

and it is actually rather cool since you don't rely on any docker command :)

Re: Nix as OS X Package Manager

#202
post #199
post #196

Having set up my last company doing all development and deployment using nix, moving to a new team which just uses pip/virtualenv and a "bootstrapping script" feels a little unnerving to start with.

Is there any good guides to get started on nix with python?

The nixpkgs manual has a section on it https://nixos.org/nixpkgs/manual/#sec-python but the key to it is that it's really mostly about managing your PYTHONPATH. You wouldn't typically be installing a python package and just expecting it to be available to a session-launched python invocation (because PYTHONPATH is not exported to the user env of a profile), instead you would probably use nix-shell or a custom-built python environment with the exact package setup you desire...

Re: Nix as OS X Package Manager

#203
post #193
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.

> This is called dogma, Then you don't know what the word "dogma" means. What I said was "In my experience." i.e. practice learned over time. This cannot be interpreted by any reasonable person as "blobs are bad, just 'cause." That kind of straw man argument leads me to conclude that similar issues are being your inability to understand the use of reproducability.

Dogma: a principle or set of principles laid down by an authority as incontrovertibly true.[1]

You aren't offering any evidence or justification besides the statement. I might as well say, "in my experience, ``reproducability (sic) is a waste of time''" -- what's the point of that?

Instead, I'm providing concrete examples of why it's a waste of time, and rather than anyone arguing the contrary, they're doing exactly what you're doing: Repeating that there's some point of "reproducability" (sic). There isn't, you're wrong. End of.

But whatever, my background isn't physics, so what could I possibly know? Running engineering teams for the last two decades that have to develop and deal with high volume, high uptime application servers only means my systems have to work and make money, not that they be "reproducable" (sic).

[1]: http://www.merriam-webster.com/dictionary/dogma

Re: Nix as OS X Package Manager

#204
post #59

Earlier quoted context omitted.

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…

give pypi2nix a try and ping me on irc if it fails (nick: garbas)

https://github.com/garbas/pypi2nix

Re: Nix as OS X Package Manager

#205
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…

I mean, that's exactly what a Dockerfile is for. I don't know of anyone seriously using Docker that isn't using Dockerfiles exclusively. I only know of a single time when it's valuable to "commit" a new image (recovering logs from a stopped container). None of which is to detract from Nix. Nix+Docker is a powerful combination. It takes Docker's declarative nature all the way down to the compiler used to build the bit…

There's a little company called 'RedHat'...

https://github.com/openshift/source-to-image

Re: Nix as OS X Package Manager

#206
post #165

Earlier quoted context omitted.

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

They're all available: $ pkgin se python3 python35-3.5.1nb2 Interpreted, interactive, object-oriented programming language python34-3.4.4 Interpreted, interactive, object-oriented programming language python33-3.3.6nb3 Interpreted, interactive, object-oriented programming language along with a bunch of pre-packaged modules: $ pkgin avail | grep ^py3 | wc -l 1412 Let me know if anything you need is missing and I'll ad…

Thanks. I had to look back at my notes. I had issues with matplotlib and few other packages at the time with python 3.4, due to python not being built as framework.

I have just found a related issue: https://github.com/joyent/pkgsrc/issues/331 Unfortunately, from what I read there, I have still to use homebrew or install from python.org (with those I have no issue). I really enjoyed pkgin otherwise.

Re: Nix as OS X Package Manager

#207
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…

I'm going to give it a try for a while, thanks.

Re: Nix as OS X Package Manager

#208
post #166

Earlier quoted context omitted.

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.

And again, you don't need to have any understanding of asbestos in order for the gloves to work. You can believe that they are magic gloves from God, and they will work just as well.

Re: Nix as OS X Package Manager

#209

Earlier quoted context omitted.

Ex-Gentoo dev here. It is not the same. Gentoo emerge runs in place, and you can definitely break your system with a broken build. NixOS on the other hand, builds everything in sandboxes that only expose the requested dependencies. Builds are almost 100% deterministic. The cherry on top is that your system installation is simply a package consisting of all other packages and configuration symlinked together, and you…

the non-deterministic nature is what I was getting at. I worked at a place where they'd spin up a new gentoo box for a dev with stock "emerge foo" and let everything run up. Then 3 weeks later, they'd do it again for the next dev, and they'd have many diff versions. I know they weren't "doing it right", but they were doing it the default way they learned, and it caused a lot of problems. Thanks for the info/clarifica…

It's been a LONG time, but when you build gentoo packages you can save the builds, right? Then if you bring up identical servers, you can just install from precompiled packages.
Post reply on HN