[HN Gopher] macOS Nix Setup (an alternative to Homebrew) (2020)
       ___________________________________________________________________
        
       macOS Nix Setup (an alternative to Homebrew) (2020)
        
       Author : notamy
       Score  : 193 points
       Date   : 2021-07-13 19:34 UTC (3 hours ago)
        
 (HTM) web link (wickedchicken.github.io)
 (TXT) w3m dump (wickedchicken.github.io)
        
       | nuker wrote:
       | So how do i do 'pip3 install requests' for example?
        
         | myWindoonn wrote:
         | $ nix-shell -p python3Packages.requests
         | 
         | Nix generally only manifests temporary environments, rather
         | than mutating global state. For a more Pythonic environment,
         | try the direnv integration, which will let you both `use nix`
         | and also `use python3` together, as long as it's in that order.
        
       | _query wrote:
       | I've been using nix on macOS as my primary package manager for
       | years. Really love it! Specifically nix-shell is a blessing a you
       | can quickly try out things without worrying about breaking some
       | other packages on the system.
       | 
       | Initially we've only used nix for development at my company, but
       | now we're also running most of our servers with NixOS. This
       | allows us to use our dev package definitions in production, so
       | our dependencies are always in sync between dev and prod. I've
       | written a blog post about all the advantages we get with nix in
       | our framework IHP a while ago, if you're curious, check it out:
       | https://ihp.digitallyinduced.com/blog/2020-07-22-why-ihp-is-...
       | 
       | If you're using an older mac and have troubles with installing
       | nix, try out the new installer in this GH issue:
       | https://github.com/NixOS/nix/pull/4289 (the command is in the
       | "Try it out" section). It's already merged, but not released yet.
       | So far this has solved all the issues on older macs for me.
       | 
       | Also check out https://nix.dev/ which has many great resources to
       | get started :)
        
       | mitchellh wrote:
       | I switched my primary dev environment to NixOS in a graphical VM
       | on macOS towards the end of 2020 and I love it:
       | https://twitter.com/mitchellh/status/1346136404682625024?s=2...
       | 
       | Previously, I used Nix on Mac (as this blog post suggests) but I
       | had enough "gotchas" with Nix on Mac that I decided to go full
       | NixOS.
       | 
       | For those who ask why a VM or why I keep Mac around at all: I
       | like macOS for everything else besides dev work. I use iMessages
       | heavily, I like the Mac App ecosystem such as calendars, mail
       | clients, etc. This gives me the best of both worlds.
       | 
       | I usually run this on an iMac Pro but also have a MacBook Pro. It
       | runs great on either. It's also really nice with Nix to update
       | one machine and the other is just one command away from being
       | equivalent.
       | 
       | I recognize this is a "weird" setup but wanted to point it out
       | since it seems relevant to this post.
        
         | rphln wrote:
         | Out of curiosity, have you experimented with accessing the VM
         | through SSH? If so, what was it like?
         | 
         | I could see myself using a similar setup down the line, but
         | having two graphical environments seems like it'd be somewhat
         | distracting or fussy.
        
           | mikepurvis wrote:
           | I do a similar setup to this on Windows (WSL) and previously
           | on a Mac (Parallels + Ubuntu). In both cases it's exclusively
           | SSH access using an outer-system terminal, and as far as
           | editors, a mix of screen/vim/whatever in the terminal, and
           | VSCode with remote editing.
        
         | res0nat0r wrote:
         | Another cool thing is you can copy an entire nix closure to
         | another host if you want to replicate it exactly somewhere
         | else.
         | 
         | https://nixos.org/manual/nix/unstable/command-ref/nix-copy-c...
        
         | heavyset_go wrote:
         | I run the opposite of this, and run Linux with Nix on a Mac,
         | and run macOS in VM with VFIO passthrough for macOS
         | development.
         | 
         | I've found that native Linux makes for an excellent dev
         | environment.
        
           | philsnow wrote:
           | You're running linux (with nix installed) on the bare metal
           | of a mac, and then a VM on top of that running macos (with
           | VFIO passthrough so it's not dog-slow?), is that right?
           | 
           | Performance is pretty reasonable? APFS works fine in this
           | setup? No gotchas with drive encryption? ... actually, if
           | your machine does use drive encryption, which is doing it,
           | linux or mac? I don't know enough about mac hardware to know
           | if there is some mac boot environment that handles encryption
           | and then hands off to the OS (be it macos or linux).
        
           | sureglymop wrote:
           | I've had a vfio setup for a year now, passing various
           | hardware to Windows and Linux VMs but finally I just
           | converted it to a regular dual boot setup.
           | 
           | I figured since I am passing through all this hardware anyway
           | it might as well all directly access it.
           | 
           | Now with SR-IOV that would be an entirely different story.
        
         | fnord123 wrote:
         | > I like the Mac App ecosystem such as calendars
         | 
         | Does Calendar actually work for you?
        
           | borski wrote:
           | Yes, it's fine. I've since moved to fantastical but the stock
           | calendar app was fine.
        
         | Tempest1981 wrote:
         | Do you run git in the VM too? Or on macOS?
        
         | rubiquity wrote:
         | I went down this route as well and am the happiest I've been
         | when it comes to managing dependencies and creating builds. I
         | ended up taking it one step further because Apple kept breaking
         | my hypervisor (xhyve) with every new macOS release. I built a
         | new workstation that runs NixOS and wayland/sway. I still have
         | my MacBook Pro for when I need macOS comforts or if I don't
         | feel like being at my desk I can just SSH into the workstation.
        
         | numbsafari wrote:
         | It's really not weird at all, IMHO.
         | 
         | If you look at ChromeOS, it's actually relatively mainstream.
         | 
         | Most of us need a locked down desktop environment more than we
         | realize. The UNIX/POSIX shell environment works really well for
         | our specific kind of work (writing software), but it's full of
         | security holes and gotchas. A lot of people talk about Apple as
         | wanting to "own" everything, but the trend in securing consumer
         | OS environments is clearly trending in this direction. Starting
         | with research examples like Qubes, and all the mainstream
         | security efforts in Windows, and ChromeOS.
         | 
         | Working with a VM that you can torch and rebuild is ultimately
         | the best of both worlds.
         | 
         | What would be really cool is a Mac OS app for managing
         | Vagrant... Basically a competitor for Docker Desktop for Mac
         | that used VMs instead of Docker.
        
           | unicornfinder wrote:
           | What you've described is precisely why I love WSL - you can
           | nuke and rebuild your Linux setup easily. It's fantastic
           | honestly.
        
             | leucineleprec0n wrote:
             | Yes, this is what's so alluring about WSL, whereas with
             | homebrew on my M1 setup I have an utter clusterf&$& of a
             | paper trail across my desktop that is a real PITA to
             | plausibly reverse course, modulo Time Machine backups.
        
               | robenkleene wrote:
               | I use a `brew bundle` to help manage this. Make a
               | `Brewfile` listing homebrew installs, then `brew bundle
               | cleanup` to delete everything that's not in that file.
               | This way I can try something out and easily delete it
               | (and the dependencies it installed). It also obviously
               | makes it easy to setup a new machine.
        
             | numbsafari wrote:
             | Yep. Crostini under ChromeOS operates more or less the same
             | way. It's also why I personally am done with the homebrew
             | approach.
             | 
             | I was using VMs to address the disaster that is the Windows
             | Registry as a developer back in the early 2000s. Homebrew
             | is such an amazing step backwards in that regard.
             | 
             | I have a feeling that Terminal.app is headed this direction
             | on Mac OS, but Apple is taking their sweet time navigating
             | the migration since everyone gets pissed off whenever they
             | fix a security/reliability problem. Could you imagine the
             | uproar if the next version of Mac OS worked the way
             | ChromeOS does? (ps., there's nothing stopping you from
             | running Firefox on ChromeOS, I've done it).
        
               | viraptor wrote:
               | > I was using VMs to address the disaster that is the
               | Windows Registry
               | 
               | What do you mean?
        
               | numbsafari wrote:
               | The general issue one runs into on Windows where you,
               | say, install a bunch of dev tools and then, at some
               | point, your registry gets corrupted and you find yourself
               | needing to reinstall everything.
               | 
               | If you run your tools, and do your testing, inside of
               | VMs, you can quickly "restart" from a known good state.
               | 
               | The Windows Registry is a lot like /etc in Unix-like
               | environments. In either case, all that configuration can
               | get co-mingled and corrupted and you have to start over.
               | 
               | VMs are a great way to solve that problem for developers.
        
               | viraptor wrote:
               | Registry corruption since w2k is pretty much solved. It's
               | a database with a WAL-style transaction log. If registry
               | corruption is something that happens to you more than
               | once, I'd check the storage since there's probably a lot
               | more that's getting corrupted... Otherwise - keep full
               | disk backups.
        
           | heavyset_go wrote:
           | > _A lot of people talk about Apple as wanting to "own"
           | everything, but the trend in securing consumer OS
           | environments is clearly trending in this direction. Starting
           | with research examples like Qubes, and all the mainstream
           | security efforts in Windows, and ChromeOS._
           | 
           | This is because Google and Microsoft want to own everything,
           | as well. It's not a coincidence that Apple, Google and
           | Microsoft's security implementations enshrine each of them as
           | ultimate gatekeeper and single source of truth for security
           | on their respective operating systems.
           | 
           | It is interesting that you bring up Qubes OS, because its
           | security model doesn't depend on Invisible Things Lab, the
           | Qubes developer[1], deciding what can or can't run on Qubes
           | OS.
           | 
           | In fact, if a security model that depended on a company like
           | Red Hat authorizing what can or can't run on Linux, it would
           | be rightly criticized as Red Hat trying to "own" everything
           | instead of developing a secure system at the OS level. Yet
           | Apple, Google and Microsoft are doing just that.
           | 
           | [1] https://invisiblethingslab.com/
        
             | numbsafari wrote:
             | I think we are really conflating "app store distribution"
             | and "the POSIX userland isn't workable in a modern security
             | environment for end-users". POSIX apps run as the user,
             | when they really need to be run with their own identity.
             | Most often we should use the identity of the "developer".
             | 
             | Do I want Firefox to have access to my Contacts? My Photos?
             | Do I want Facebook to have that access? To all of them, or
             | just ones that I select? Should my disk utility have the
             | ability to send data over the network? My IDE? My IDE
             | plugins?
             | 
             | This has nothing to do with "stores", and everything to do
             | with the security model and the UI needed to make it work.
             | e.g., when I run `grep -e "Something" -r ~/src`, I assume
             | grep is going to read all of the files in ~/src. But in the
             | basic POSIX environment it can access anything I can
             | (including, say, ~/.ssh) and open up any old socket it
             | wants and send data wherever it chooses. Have you read
             | every line of code of every package you've installed?
             | Rather than relying on 'trust', 2021 requires that we
             | actually have some security model that doesn't rely on
             | trust, but explicit permissions and grants, and workable UI
             | for defining that. Wouldn't it be nice if bash arranged a
             | read-only capability granted to the grep process for all
             | files under ~/src based on the above command, and if the
             | grep executable itself had no inherent permissions at all?
        
               | viraptor wrote:
               | That's pretty much selinux. We don't have a nice ui for
               | it, because what you described is actually pretty
               | complicated to achieve. But it actually works. Today.
        
               | mikepurvis wrote:
               | Socket/port activation in the init system tries to be a
               | piece of this puzzle too, though obviously it's far from
               | the whole story.
        
             | chrisfinazzo wrote:
             | > This is because Google and Microsoft want to own
             | everything, as well. It's not a coincidence that Apple,
             | Google and Microsoft's security implementations enshrine
             | each of them as ultimate gatekeeper and single source of
             | truth for security on their respective operating systems.
             | 
             | To a close approximation, 99% of regular users (let's just
             | say people who are not developers by profession) _do_
             | implicitly trust their respective OS vendors. To suggest
             | otherwise suggests a level of paranoia which would make it
             | impossible to ever have a stable system and get anything
             | done.
        
               | numbsafari wrote:
               | It's funny, because I actually agree with both of you.
               | 
               | We should generally trust our primary OS vendor, because
               | otherwise we're all going to need therapy.
               | 
               | But we shouldn't _have_ to trust them. That is, the
               | system should be designed such that we have some amount
               | of  "defense in depth" where a mistake by Apple during
               | the review of one of the 3.5 million apps doesn't result
               | in an exploit.
               | 
               | I think this is why Apple and the others are trending
               | towards the design that they are, because a deep
               | capability approach that's integrated into the UI helps
               | offload some of the complexity and overhead of managing
               | that liability at scale.
        
             | babypuncher wrote:
             | > Apple, Google and Microsoft's security implementations
             | enshrine each of them as ultimate gatekeeper and single
             | source of truth for security on their respective operating
             | systems.
             | 
             | Who do you propose should shoulder this responsibility? The
             | vast majority of users lack the expertise to take it on
             | themselves.
        
           | jbenner-radham wrote:
           | You might be interested in: https://www.vagrantmanager.com/
        
             | numbsafari wrote:
             | I'm aware of it. Hasn't been updated in a long time, and
             | you need to otherwise install vagrant and a VM manager
             | separately (fortunately, it doesn't ironically tell you how
             | to do so via homebrew...)
             | 
             | I think a first-class vagrant app for Mac OS would (a) be
             | available in the App Store for simplified VPP deployments
             | (b) install vagrant and (c) either come with a lightweight
             | VMM over Hypervisor.framework and/or work with other active
             | VMMs like Fusion, Parallels or even Docker Desktop.
             | 
             | Vagrant was born of the CLI, but I think in 2021 it needs
             | to embrace its role as a bridge between the GUI and CLI.
             | Just my opinion, though...
        
           | circularfoyers wrote:
           | Fedora Silverblue is potentially where the future of the
           | Linux desktop might end up. It improves on security
           | significantly, where the system is read only, similar to
           | macOS, and all user programs are sandboxed within flatpaks
           | (migrated from the preexisting RPMs of these programs).
        
             | jcastro wrote:
             | Have you been able to get nix working in silverblue? The
             | read-only fs makes making a `/nix` not very
             | straightforward.
        
         | cyberpunk wrote:
         | What hypervisor/vm software are you using?
         | 
         | I'm running some Linux vms under parallels on a m1 and the
         | graphics performance could be better..
        
           | Gaelan wrote:
           | Looks like VMWare from the tweet they linked.
        
           | mitchellh wrote:
           | VMware Fusion. I don't use an M1 Mac right now (I have one
           | for testing but not primary dev work).
        
             | reddit_clone wrote:
             | > VMware Fusion
             | 
             | Does it work? When I upgraded to BigSur and Fusion 12 the
             | networking just stopped working.
             | 
             | VMs dont work with NAT at all. In Bridged mode, it
             | partially works. Completely stops if I get the Mac host in
             | to company VPN.
             | 
             | All of this used to work prior version of Mac OSX and
             | Fusion 11.
        
         | Scarbutt wrote:
         | Your setup is normal, the weird part is running a GUI in the
         | linux VM. Simpler, why not just use ssh? (since you are vim
         | user and all)
        
         | sigjuice wrote:
         | Does copy/paste work between the host and the VM?
        
           | mitchellh wrote:
           | Yes (via VMware Tools)
        
         | exdsq wrote:
         | I think it's becoming more common. I do the same with a
         | Pixelbook as my main computer nowadays!
        
         | gigatexal wrote:
         | I tried a graphical VM on my Mac but it was too slow. How are
         | you getting around that?
        
         | smoldesu wrote:
         | I envy your patience. I had to drop MacOS altogether out of
         | frustration that there were no good package managers, and VMs
         | simply don't cut it for me. Nowadays, I run an inverse setup: I
         | do pretty much everything in Arch, with a few Wine prefixes to
         | solve Windows compatibility, and a healthy combination of
         | Darling and QEMU to spin up MacOS instances.
        
           | Svetlitski wrote:
           | Genuinely curious, what didn't you like Homebrew (assuming
           | you tried it)?
        
             | heavyset_go wrote:
             | Another HN user did a write up on Homebrew[1] that I agree
             | with.
             | 
             | My main gripe is that Homebrew would regularly break my
             | Python virtualenvs with linking errors. Meanwhile on Linux,
             | I have virtualenvs that I created 9 years ago that still
             | just work.
             | 
             | These days you might be able to sidestep that issue by not
             | using Python from Homebrew at all, but installing and
             | managing it with Pyenv instead.
             | 
             | [1] https://saagarjha.com/blog/2019/04/26/thoughts-on-
             | macos-pack...
        
               | Groxx wrote:
               | `brew pin python` and it'll stop that from happening.
               | 
               | but yeah, this is a constant source of pain, and I end up
               | helping people at work fix it probably on a weekly basis
               | (or more often). python bin-envs are such a hassle.
        
           | handrous wrote:
           | Meanwhile, I find macOS sticky in part _because of_ the
           | package manager (homebrew).
           | 
           | In particular, I've not seen a package selection so good and
           | so consistently up-to-date, with so very little fiddling or
           | upkeep to add or maintain 3rd-party repos, since I was on
           | Gentoo--and portage broke (in whole, or just had broken
           | individual packages) a lot more than homebrew does (which is
           | almost never). I can't think of a single thing I use that
           | isn't available and well-maintained on it, open or closed
           | source. Even obscure things often just install on my first
           | guess at the package name, no muss, no fuss.
           | 
           | Now, what I _don 't_ use it to do is to manage project
           | dependencies, but then I don't like using, say, the "system"
           | PostgreSQL or Nodejs or whatever even on Debian, either,
           | unless I'm _using them_ directly and not _making them part of
           | a project_ that will need to be distributed or deployed
           | elsewhere and worked on by others. I 'm entirely fine keeping
           | core OS parts, my personal software I use, and management of
           | individual project dependencies, strictly separate--in fact,
           | having worked this way, I prefer it.
           | 
           | I could be tempted away by a similarly-great and high-quality
           | package selection, maybe, but that would be table-stakes
           | before we even get into the rest of how the package manager
           | operates.
        
             | smw wrote:
             | Just fyi, you can use homebrew on linux.
        
           | viraptor wrote:
           | Does Darling work for anything serious these days? What apps
           | are you running on it?
        
       | sirodoht wrote:
       | I'm slowly venturing a full switch from brew to nix (mainly due
       | to its slowness) using nix-env and this guide:
       | https://www.youtube.com/watch?v=NYyImy-lqaA
       | 
       | It's been a few weeks. Concerns until now:
       | 
       | * Things like fzf have bash completion accompanying files. I have
       | not figured out where these reside using nix.
       | 
       | * Things like mysql make heave use of directories such as
       | /usr/local/var/mysql or similar. I was unsuccessful in surpassing
       | permission problems with these.
        
         | pxc wrote:
         | > Things like fzf have bash completion accompanying files. I
         | have not figured out where these reside using nix.
         | 
         | Bash completions get installed under Nix profiles (yours,
         | root's (a.k.a., the 'default profile'), or the 'system'
         | profile, if you're using nix-darwin or NixOS), just like
         | binaries.
         | 
         | On my system, I have some bash completions under my user
         | profile, in                    /nix/var/nix/profiles/per-
         | user/$USER/profile/share/bash-completion/completions/
         | 
         | and some in the system profile, in
         | /nix/var/nix/profiles/system/sw/share/bash-
         | completion/completions
         | 
         | If you use a shell installed from Nixpkgs, it'll automatically
         | pick up on all such completions installed to your profiles
         | (which come bundled with the packages they're for). (To try
         | this with bash, make sure to install `bashInteractive` rather
         | than just `bash`.)
         | 
         | If you use a shell configured by a Nix module system, like
         | NixOS or Nix-Darwin, it will provide an option to enable the
         | installation of such completions to your system profile, which
         | you can enable like this: https://github.com/LnL7/nix-
         | darwin/blob/a7492a8c76dcc702d0a6...
         | 
         | > Things like mysql make heave use of directories such as
         | /usr/local/var/mysql or similar. I was unsuccessful in
         | surpassing permission problems with these.
         | 
         | It's clear that you're pointing to a real issue, but there's
         | either a typo or a misunderstanding above. If your `mysql`
         | binary really does spit out messages about /usr/local/, it
         | didn't come from Nixpkgs. But if it comes from Nixpkgs, it
         | might be emitting similar complaints about directories under
         | /nix/store.
         | 
         | The explanation: Nix packages don't know or care anything about
         | /usr/local, but they are compiled so that they think all of
         | their 'prefixes' (e.g., what by default on a system are just
         | /usr, /lib, /etc, etc.) live in package-specific directories
         | under /nix/store. It's an important part of Nix's design that
         | everything in the store be immutable, and so everything there
         | is marked read-only.
         | 
         | The solution: to use stateful services like databases that you
         | install from Nixpkgs, point them to writeable directories
         | outside of the Nix store to use for their data storage. You can
         | do this manually for mysql with options like
         | `--datadir=/some/writeable/path/you/own` and similar. These
         | same options are used inside Nix module systems when they
         | enable configuration of services like MySQL, e.g., here:
         | https://github.com/NixOS/nixpkgs/blob/nixos-21.05/nixos/modu...
         | 
         | Hope that helps!
        
         | Nullabillity wrote:
         | > * Things like fzf have bash completion accompanying files. I
         | have not figured out where these reside using nix.
         | 
         | In general, ~/.nix-profile/share/bash-completion/completions/,
         | although fzf in particular seems to have its in ~/.nix-
         | profile/share/fzf/completion.bash. To be honest, I'm not really
         | sure about why.
         | 
         | In general, ~/.nix-profile is more or less the Nix equivalent
         | to /usr.
         | 
         | > * Things like mysql make heave use of directories such as
         | /usr/local/var/mysql or similar. I was unsuccessful in
         | surpassing permission problems with these.
         | 
         | If you're not running the services as system-level services,
         | override their state directories. In the case of MariaDB that'd
         | mean something like `mysqld --datadir=~/var/mysql`.
        
       | azalemeth wrote:
       | One thing I'd love to know is what the advantages of the
       | different systems are, objectively. I've always used macports,
       | from the very early days, and I just use it because it works, and
       | I know its quirks. I remember brew starting, and thinking "oh,
       | that looks interesting". Yet I never really felt a compelling
       | reason to change.
       | 
       | This article is refreshingly honest about why the author decided
       | to give nix a try, and I very much appreciated that. A large
       | chunk is "it's new and I wanted to try it out", combined with
       | deterministic update times, which I respect. Is there a detailed
       | technical comparison of macports, homebrew and nix anywhere?
        
       | mikepurvis wrote:
       | > Unpredictable command times.
       | 
       | As a novice Nix user, I would say that I've hit a certain amount
       | of this too. Basically every time you update your channel, it's a
       | dice roll how much you're going to have to rebuild or re-
       | download.
       | 
       | Now, it's easy to let it run in the background or
       | interrupt/resume it at any time, so that at least is a plus-- and
       | it does provide a clear indication of how much it's downloading,
       | and how many packages are being built.
        
       | X6S1x6Okd1st wrote:
       | I'm a big fan of Nix!
       | 
       | nix on OSX was my gateway drug to nixos. Nixos is much more
       | intimidating & when you stray outside of what is supported by
       | nixpkgs the learning curve really ramps up.
       | 
       | I wouldn't be surprised if we start seeing shell.nix and
       | build.nix showing up in more and more OSS projects & it spreads
       | mostly that way.
        
       | varenc wrote:
       | Brew's slowness is a huge pain point. A basic `brew info` command
       | takes 1.8 seconds and requires executing 6 ruby processes. (with
       | online analytics disabled)
       | 
       | And `brew search` is so slow that I've just made a function[0] to
       | search taps locally for formula/cask filenames matching my query.
       | Takes 0.08 seconds instead of 10-20 seconds.
       | 
       | Makes me want to try `nix`. Anyone have experience using them
       | both together?                  [0]        brewSearchFast() { fd
       | "$1" -e rb /usr/local/Homebrew/Library/Taps }
        
       | abathur wrote:
       | If you want to try this but balk at the ~rough install experience
       | around the Nix volume/encryption: a bunch of work I did to sand
       | this down last Fall was merged into master this Spring.
       | 
       | There are some headwinds wrt backporting those improvements to
       | include them in the 2.3.x release series, but you should be able
       | to take advantage of them in the meantime via the installer
       | numtide publishes from master: https://github.com/numtide/nix-
       | unstable-installer (no special flags needed).
        
       | NelsonMinar wrote:
       | How is Fink doing these days? It looks still actively maintained.
       | The advantage with Fink is it uses dpkg; I winced as I watched
       | years of Homebrew reinventing a Unix package system, badly.
        
       | gigatexal wrote:
       | Pin your home brew versions and upgrade at non-critical times and
       | you'll be fine? I've been doing this for years and not had any
       | issues. :shrug:
        
         | jeofken wrote:
         | A feature declarative programming gives Nix is being able to
         | commit a list of dependencies in the file default.nix, and when
         | entering just run $nix-shell, and have the right version, and
         | it works for my Linux colleagues as well.
         | 
         | Typing on the go so may have missed a param
        
           | adkadskhj wrote:
           | How does default.nix handle dependencies? From what i've (i'm
           | on NixOS) seen you just see something like `gcc` or
           | `openssl`, with no clue what version.
           | 
           | Tbh i've found Nix very very lacking in the dependency
           | department. What i _want_ is something like Cargo.toml from
           | Rust (or maybe packages.json/yarn.lock if you're familiar
           | with NodeJS), which compiles to a Cargo.lock. Instead what i
           | have is a name for a dependency with no clue what version the
           | writer expected, or what version my computer will install.
           | 
           | Pulling a new commit from nixpkgs repo can lead to chaos and
           | random things update with no rhyme or reason.
           | 
           | Flakes, in alpha i believe, is the first thing from Nix that
           | actually felt repeatable. But even with Flakes i still don't
           | know what version anything is, but at least i know what
           | concrete commit sha worked for me and can always revert as
           | needed.
           | 
           | My next NixOS install will use Flakes with a very granular
           | approach. The OS on one package ref, and other packages all
           | have their own isolated refs. This will be verbose and
           | bloaty, but being able to update Vim without my OS going
           | crazy will be really nice.
           | 
           | I'd still like Flakes to behave more like Cargo.lock, but
           | it's at least progress.
        
       | stockholm_sloth wrote:
       | Interesting read as I am a huge OSX and CLI fan. Thanks for that!
       | I too am worried by the root file system "security enhancements"
       | in recent versions of OSX that make it harder and harder for me
       | to do my job (develop website backends).
       | 
       | However I may wait to try Nix until it has better support for my
       | primary tools (mainly php and ruby based websites) ... because I
       | LOVE the simplicity of homebrew. And if there are any homebrew
       | developers reading this, I frickin' love you guys. You make
       | everything I need to do extremely easy.
        
         | SavantIdiot wrote:
         | If php and ruby are your primary packages, why would you need
         | something other than macports? Both are up to date with the
         | latest versions.
        
         | FullyFunctional wrote:
         | Indeed, as a newcomer to Nix I was immediately put off by the
         | arcaness of everything. I don't want my first experience to be
         | memorized obscure paths and funky command line arguments (such
         | may justified _later_ when more advanced options are wanted).
         | I'm glad it works for people and I gather nix-env is a step in
         | the right direction, but it's IMO not quite there yet.
         | 
         | EDIT: example, why is it                   nix-env -qaP git
         | 
         | instead of                   nix search git
        
           | ianthehenry wrote:
           | It actually is! There are lots of examples of arcane Nix
           | commands, but as of Nix 2.0, you actually can type `nix
           | search git`. And it works much better than `nix-env -qa` ever
           | did.
           | 
           | Your point stands, though. For example, why is it:
           | nix-env -iA nixpkgs.git
           | 
           | Instead of:                   nix install git
           | 
           | (I know what the answer is, but still, it's a question that I
           | think a lot of newcomers are going to ask.)
        
       | defulmere wrote:
       | The author had me until he mentioned installing ripgrep
       | *temporarily*.
       | 
       | Stopped there because I don't do heresy.
        
         | luckyorlame wrote:
         | " I don't do heresy." please explain.
        
           | jahnu wrote:
           | It's a joke that they they love and depend on ripgrep so much
           | that to uninstall it would be an act tantamount to heresy
        
         | pxc wrote:
         | Seconded! I think ripgrep is my favorite of all of these next-
         | gen fundamental CLI tools.
         | 
         | For me, it replaces both grep and sed (except for in-place use
         | of the latter), because I never write complicated sed programs.
        
         | jeofken wrote:
         | It's with you for eternity, just hidden from programs unworthy
         | of its excellence. Immutable is forever :)
        
         | est31 wrote:
         | I really love the temporary installs feature of nix OS. Often I
         | just want to try some software once and don't want to use it
         | afterwards. The temporary install feature is perfect for that,
         | to help avoiding building up bloat from forgotten uninstalls.
         | 
         | But yes, you absolutely must have ripgrep.
        
         | ihumanable wrote:
         | I think one thing that's interesting about "temporary"
         | installation is that nix has this notion of "present" vs
         | "installed."
         | 
         | When you run a nix-shell the program is downloaded and if
         | necessary built and put into the nix store, after leaving the
         | shell it's all right there on your disk ("present") just not
         | "installed" into the environment.
         | 
         | This is why the first time you run nix-shell with something new
         | it downloads stuff while subsequent invocations are immediate.
         | It also means that if you liked ripgrep in a shell, installing
         | it is just has nix write out some new symlinks.
        
         | stevefolta wrote:
         | "nix-shell" is exactly how I first tried ripgrep. Of course, I
         | installed it permanently moments later.
        
         | haskal wrote:
         | Just replace "ripgrep" with "cowsay" or "neofetch" and read
         | again.
        
       | seanparsons wrote:
       | > there is no CLI equivalent to brew install that I am aware of
       | 
       | There is! You use `nix-env` for that by running something like:
       | `nix-env -iA ripgrep`.
        
       | ianthehenry wrote:
       | To others who might be interested in trying Nix instead of
       | Homebrew:
       | 
       | There _is_ a `brew install` equivalent in vanilla Nix -- `nix-
       | env` provides an imperative interface pretty similiar to `brew`.
       | 
       | `nix-darwin` is a third-party thing that tries to give you a
       | NixOS-like experience on macOS. It's not necessary if you're only
       | interested in replacing Homebrew. You can have `shell.nix` files
       | and ad-hoc environments without replacing your entire system
       | configuration.
       | 
       | Vanilla Nix is very well isolated, and you can try it side by
       | side with Homebrew to see how you like it -- one of the nice side
       | effects of Nix-installed software being independent from the rest
       | of your system is that, well, you can install whatever you want
       | without breaking the Homebrew equivalents. For example instead of
       | putting binaries in `/usr/local/bin`, Nix creates a directory of
       | symlinks to files in `/nix/store`, and you can add that directory
       | to your `PATH` if you wish.
       | 
       | I switched to Nix a few months ago and have found it... fun. It's
       | not something I would recommend if you want things to just work,
       | but if you're curious about Nix, you can learn quite a lot about
       | it from the comfort of your MacBook.
       | 
       | I wrote a little about this experience here, including how to map
       | common `brew` commands into their `nix-env` equivalents:
       | https://ianthehenry.com/posts/how-to-learn-nix/switching-fro...
       | 
       | (Warning: it's more of a rambling diary entry than a blog post.)
        
         | parkerduckworth wrote:
         | Thanks for posting this, it's very helpful.
        
         | rahen wrote:
         | Very helpful. Unfortunately Nix doesn't support aarch64 yet,
         | only x86_64...
         | 
         | It seems to be coming though:
         | https://github.com/NixOS/nixpkgs/issues/95903
        
           | tikhonj wrote:
           | I recently helped somebody get Nix set up on an M1 Macbook
           | and it seemed to work fine overall. We just used the standard
           | installer, then mostly reused a home-manager-based config
           | that I use on my x86-64 Macbook. Core stuff like Git and
           | Emacs worked with no fiddling, and the few problems we did
           | encounter seemed to be from issues in my personal config, not
           | Nix on aarch64 in general.
           | 
           | That said, we didn't try to build or use anything
           | particularly tricky--just Git, Emacs, Python and a simple
           | Haskell project so far.
        
           | ianthehenry wrote:
           | Yeah, it, like, _mostly_ works? But maybe only in multi-user
           | mode? I don 't know; I didn't read the whole thread. I don't
           | have an M1 machine, but it seems like there are binaries
           | cached for the arch in the official cache:
           | $ nix-env -qasA nixpkgs.git --argstr system 'aarch64-darwin'
           | --S  git-2.31.1
           | 
           | Which implies that it's supported in some capacity.
           | 
           | (The "S" means "there's a substitute available;" i.e. git at
           | least is cached for aarch64. Yeah, Nix's CLI... needs work.)
           | 
           | I don't know exactly what the state of it is -- i.e how many
           | packages can build natively on M1 -- but I know that the
           | Nixpkgs community has done a lot of work in the last year to
           | support M1 nicely, and I _thought_ that it was fully usable
           | at this point. But there 's a big difference between "Nix
           | works on M1" and "every package in Nixpkgs works on M1."
        
             | callahad wrote:
             | A better future is on the horizon (or here, today, if
             | you're willing to install a 2.4 pre-release): Flakes make
             | it trivial to fall back to x86_64 when aarch64 fails, and
             | the CLI experience is dramatically improved.
             | 
             | Alas, that path is probably not yet suitable for folks
             | without prior Nix experience, given how new everything is.
        
               | ianthehenry wrote:
               | Are flakes necessary for that? I would think you could
               | install x86_64 binaries manually by setting `system`,
               | even on the 2.3 branch. It seems I can do the reverse
               | thing:                   $ nix-env -iA nixpkgs.hello
               | --argstr system aarch64-darwin         $ file $(which
               | hello)         /Users/ian/.nix-profile/bin/hello: Mach-O
               | 64-bit executable arm64
               | 
               | But maybe you just mean that it does this automatically?
               | That's neat, if so. And I would expect this to be a lot
               | more annoying within a default.nix file, having to keep
               | track of two different nixpkgs imports.
        
               | callahad wrote:
               | Not automatic, but as a replacement for nix-env and nix-
               | shell, it's great. When I need an x86_64 package, I find
               | `nix shell nixpkgs#legacyPackages.x86_64-darwin.neovim`
               | easier to recall and reason about.
               | 
               | (Or `nix profile install nixpkgs#...` for a persistent
               | version of the same)
        
           | fabianhjr wrote:
           | Nix / NixOS support AArch64 (
           | https://nixos.wiki/wiki/NixOS_on_ARM ) however Apple/Mac-
           | devices don't have many drivers available nor have people
           | contributed enough time and resources to have a darwin-
           | aarch64 build farm and binary cache.
        
           | Isthatablackgsd wrote:
           | That would explain why nix-env --install kept failing because
           | I am using M1.
        
       | pxc wrote:
       | I find that the isolation of Nix/Nixpkgs makes it pretty natural
       | to use it in tandem with Homebrew.
       | 
       | I don't need any CLI tools that aren't in Nixpkgs anymore, so I
       | use Homebrew exclusively as an installer-fetcher-and-runner
       | rather than a source-based package manager (i.e., only for
       | 'casks' rather than for 'formulae'), and the combination is very
       | nice.
       | 
       | Nix similarly plays nice with Pkgsrc and MacPorts, so if you're
       | interested in switching away from Homebrew but unsure about Nix,
       | there's no special work you have to do to install one of those
       | alongside Nix for use as an escape hatch that doesn't involve
       | Homebrew.
        
       | domenkozar wrote:
       | We've just made Nix support Apple Silicon natively!
       | 
       | I've also been working on tutorials for beginners at
       | https://nix.dev, for example how to set up declarative developer
       | environments.
        
         | mark_l_watson wrote:
         | Thanks, that was a question in my mind. Brew does a fairly good
         | job on M1 Macs by maintaining two environments, one M1 native,
         | and one using Rosetta.
        
       ___________________________________________________________________
       (page generated 2021-07-13 23:00 UTC)