4 ms·

You 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 you

by takeda 6y ago

You 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 ago
This 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 ago
  For 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 ago
Unfortunately, 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 ago
  There 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 ago
    The 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 ago
      It'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.
      - foldr 6y ago
        I'm sure there are reasons for it, but it still sucks. It ought to be possible to use binary caches and still swap out the path. (Modifying a string in an ELF executable isn't that hard.)
        bennofs 6y ago
        Modifying a string in ELF is hard. As long as the string has the same length as the original one, it has a good chance to work (but still fails for compressed data). But if you want an arbitrary directory, you need to replace it with a different length path, and that will probably break a lot of things.
        6y ago
tomberek 6y ago
I'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 ago
  I 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.

by takeda 6y ago

fiddlerwoaroof 6y ago

This 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 ago
For 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 ago

Unfortunately, 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 ago
There 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 ago
  The 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 ago
    It'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.
    - foldr 6y ago
      I'm sure there are reasons for it, but it still sucks. It ought to be possible to use binary caches and still swap out the path. (Modifying a string in an ELF executable isn't that hard.)
      - bennofs 6y ago
        Modifying a string in ELF is hard. As long as the string has the same length as the original one, it has a good chance to work (but still fails for compressed data). But if you want an arbitrary directory, you need to replace it with a different length path, and that will probably break a lot of things.
        6y ago

tomberek 6y ago

I'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 ago
I 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.