8 ms·
We're using Nix where I work as well, and while I can say it was not the most user-friendly to set up, once we got it in place it has reliably worked for the la
by austinl 6y ago
We're using Nix where I work as well, and while I can say it was not the most user-friendly to set up, once we got it in place it has reliably worked for the last two years.
We used to have a long and flaky shell script which set up the development environment for new engineers and CI machines (for iOS development on macOS, specifically). Now we have a very simple script which just installs nix and runs alls builds through the nix-shell. This makes builds on local machines and CI very easily reproducible. It also means that when dependencies change, we just update our nix config, and the new dependencies will automatically be fetched for all of our engineers and CI machines — no need to manually re-run the setup script.
This is my favorite part of Nix — you can do `nix-shell --run "<some command>"`, and it will make sure you have all of the correct dependencies (downloading if necessary), then run the command with those exact dependencies. This is especially magical when engineers working on other platforms have conflicting dependencies — a problem we no longer need to worry about.
- takeda 6y agoYou can use Nix on MacOS X and with nix you don't need brew. I used it for few years that way. If you use nix-darwin + home-manager you can also configure your mac the way you would NixOS. Amazing tools that discovered not long ago (they aren't specific to os x) is: niv - makes pinning to specific repos/versions in repos much easier which helps with reproducibility, especially pinning of nixpkgs version which is now controlled in your source code. direnv + lorri - you no longer need to invoke nix-shell just cd the directory and all tooling you need for your project is suddenly available which is AWESOME. Here's an example of using them together with packaging a python project[1] if you have lorri and direnv installed and cd to the directory, not only you have the right python version installed but also all dependencies and even the "hello" command becomes available, as if you installed it through `pip -e .` [1] https://github.com/takeda/example_python_project https://github.com/takeda/example_python_project
- fiddlerwoaroof 6y agoThis is only sort of true: I’ve found that Nix on a Mac is great except that about 10% of the derivations just don’t work: some are excluded explicitly as broken and some just fail in strange ways and need lots of debugging.
- takeda 6y agoFor me, most of packages worked, the ones that didn't were actually justified to not work, definitively far more than 10% (it was more like 90% for me). The stuff that didn't work was justifiably linux specific, except one thing, that now memory escapes me what it was.
- jdlshore 6y agoUnfortunately, the security updates introduced in MacOS Catalina have made installing Nix on the latest version of MacOS a fairly involved process.[1] I looked at using it when I rebuilt my computer recently and decided to wait until it was more baked. [1] Catalina restricts which directories can be added to the root dir. Nix uses /nix.
- endgame 6y agoThere is a way to deal with the latest round of developer-hostile changes from Apple: https://github.com/NixOS/nix/issues/2925#issuecomment-604501661 https://github.com/NixOS/nix/issues/2925#issuecomment-604501... documents the workaround but if you don't have a direct link it's almost impossible to find because GitHub's UI is terrible.
- foldr 6y agoThe problem here really seems to be with nix. The /nix path shouldn't be hard coded. (Security concerns aside, I don't want a package manager to clutter up my root directory.)
- casept 6y agoIt's necessary to hardcode paths in order to ensure that the exact version of a dependency is linked into the executable. Without this mechanism, nix packages would not be reproducible and self-contained. Also, the path isn't really hardcoded. You can use a custom path, but that means you can't use binary caches.
- tomberek 6y agoI've had luck with using the approach in here https://nixos.wiki/wiki/Python#Emulating_virtualenv_with_nix_shell https://nixos.wiki/wiki/Python#Emulating_virtualenv_with_nix... because it allows the escape hatch of using pip if something isn't packaged and I want to quickly try something out. I have also been meaning to try mach-nix which may obviate the need for pip at all. Having a good standard skeleton for a python/nix project would be super helpful to add to the wiki, etc.
- takeda 6y agoI tried multiple solutions myself, this one is the closest to what I want, because: - overlays the packages on top of nixpkgs - understands setup.cfg and can get dependencies from it It is still not perfect, but when I find some time I think to submit a PR to nixpkgs to improve setupcfg2nix. Particularly it doesn't understand tests_require which you can list dependencies to run unit tests. Nix has equivalent checkDepends.
- lilyball 6y agoBy this do you mean developers doing local builds still run their builds at the command-line via nix-shell and don’t ever build from Xcode directly? That sounds very awkward.
- austinl 6y agoNot at all — you can control what commands are actually executed when developers hit the play button or do ⌘+B/⌘+R in Xcode. Xcode is fundamentally just an IDE, even though we forget that sometimes since it's traditionally coupled so tightly with xcodebuild.
- lilyball 6y agoOk so developers would normally just have an external build target selected as the active target? I assume this means you lose all of Xcode's scheme editor capabilities though.