6 ms·

I once tried to use it but it simple was not able to use Android-SDK /adb in it. Then I never used it again and fell back to arch linux.

exe34 2y ago
$ nix-shell -p android-tools [nix-shell:~]$ adb --version Android Debug Bridge version 1.0.41 Version 35.0.1-android-tools Installed as /nix/store/dxdygi06ixq7y419hmc4skz4cdzbcnwf- android-tools-35.0.1/bin/adb Running on Linux 6.10.3 (x86_64)
- fallingsquirrel 2y ago
  Sure, but it won't successfully connect to a real device unless you somehow know to also set `programs.adb.enable = true`.
  - viraptor 2y ago
    That's not nixos specific. You get special instructions for Ubuntu https://help.ubuntu.com/community/AndroidSDK https://help.ubuntu.com/community/AndroidSDK Arch https://wiki.archlinux.org/title/Android_Debug_Bridge https://wiki.archlinux.org/title/Android_Debug_Bridge Gentoo https://wiki.gentoo.org/wiki/Android/adb https://wiki.gentoo.org/wiki/Android/adb ... And the adb option is in the docs with a description of what to do https://nixos.org/manual/nixos/stable/options#opt-programs.adb.enable https://nixos.org/manual/nixos/stable/options#opt-programs.a...
    - fallingsquirrel 2y ago
      Yes, I know that and you know that. But GP wanted to install the package and move on with his life instead of debugging a connection that failed with no indication why on an unfamiliar OS. https://search.nixos.org/packages?channel=24.05&show=android-tools&from=0&size=50&sort=relevance&type=packages&query=android-tools https://search.nixos.org/packages?channel=24.05&show=android... > How to install android-tools? > environment.systemPackages = [ pkgs.android-tools ]; How was he supposed to know to ignore those instructions and go to a completely different set of docs and search for "programs.adb.enable"? Instead he gave up and switched to another distro where you install the package and it Just Works™. Even though NixOS's model is conceptually better, it loses out on tons of potential users because of usability problems like this. (I'm running NixOS btw)
      - viraptor 2y ago
        Sometimes you just need to put in some work and understand what you're doing. The author needed to search for "adb" in the docs, not the whole attribute path. With the errors, they could debug the issue like they would on any other system. But that search is for packages themselves and is correct - that's how you install it. It's not going to tell you about the configuration just like it doesn't for nginx, postgresql, or many other packages. Sometimes you "have to be this high to ride", or use a simpler system - but that comes with its own issues. (Although in this very specific example it could just to make life easier - I'll send a PR next week unless someone does it first)
        Arrowmaster 2y ago
        Why is this extra completion acceptable? On Debian I install the package adb and get the udev rules with it. I just need to connect a device and run adb commands.
        exe34 2y ago
        nixos is open source, I'm sure they'd welcome your proposed changes! they accept patches on GitHub.
        dqv 2y ago
        For the same reason that people get used to quirks on Debian (or any other distro really) that then eventually get fixed. Nobody's perfect, you live and you learn it. I use Hannah Montanix btw https://youtube.com/watch?v=2DQla5j26Qc https://youtube.com/watch?v=2DQla5j26Qc
        viraptor 2y ago
        Because nixos manages your system and nixpkgs only contains packages. Packages cannot do anything outside their installed location, so can't touch udev or groups to make the changes. There will be other apps split in the same way. The benefit is that just adding some package will never break your own configuration.
        lostmsu 2y ago
spease 2y ago
I have tried to use it for C++, iOS, Python, Flutter, Docker, MacOS binaries, an Ubuntu container, MacOS, and NixOS. In every case it became a time sink that failed to work due to broken packages and convoluted code. Core issues are that: (1) To meet nix’s goal of declarative package management, everything in nix wraps software to create a bespoke interface for nix. But the documentation for the nix interface is extremely spotty and inconsistent, where it exists at all. (2) The language is a mix between functional and shell code, to create a declarative spec. This means many mental gear shifts while reading. This is made even worse by the nixpkgs API being inconsistent, with case-specific variants of functions (eg to set a property on a package you might need to call a language-specific property setter, which is very confusing when a package is built with multiple languages) (3) Many packages are broken or unsupported on one OS or the other. Because of these, it means that you need to be a coder AND have deep Linux knowledge AND deep Nix knowledge to use it for an extended period of time. And then: (4) Nix does not cleanly integrate with the packaging for a language, or expects running an AOT tool to generate a bespoke Nix derivation from the standard tooling I and others have complained about Nix being too difficult to use for years, but the Nix community instead is more excited about flakes, which are even more convoluted than existing derivations and metastasize the existing architectural issues in nixpkgs into countless decentralized packages that will now need to be refactored if someone tries to overhaul the design of nixpkgs. From my perspective, nix flakes are like if Linux was struggling with adoption because its internal and user APIs were undocumented and frequently broken, and the kernel developers got really excited about moving all the drivers out-of-tree into separate repositories because that’s “best practices”. A killer cross-platform and project / system package management system with hermetic build environments would be a godsend. But nix’s practical implementation of that is too badly done for me to have ever been able to use it for anything but the tiniest most specialized of projects, or as a partial package manager for macOS (where I still have to install things manually or use homebrew). There are a great many things that are theoretically possible with Nix, but I don’t know anything that I could practically recommend it for.
- viraptor 2y ago
  > Many packages are broken or unsupported on one OS or the other. Report them. There's thousands of packages. Efforts like Zero Hydra Fails help, but there's still a lot to fix. If you raise an issue, it will be prioritised, because we'll know someone actually cares about it. Keep in mind that's compared to a small percent of those packages available in other systems where you're on your own - not much different than on nixos with a broken package.

exe34 2y ago

$ nix-shell -p android-tools [nix-shell:~]$ adb --version Android Debug Bridge version 1.0.41 Version 35.0.1-android-tools Installed as /nix/store/dxdygi06ixq7y419hmc4skz4cdzbcnwf- android-tools-35.0.1/bin/adb Running on Linux 6.10.3 (x86_64)

fallingsquirrel 2y ago
Sure, but it won't successfully connect to a real device unless you somehow know to also set `programs.adb.enable = true`.
- viraptor 2y ago
  That's not nixos specific. You get special instructions for Ubuntu https://help.ubuntu.com/community/AndroidSDK https://help.ubuntu.com/community/AndroidSDK Arch https://wiki.archlinux.org/title/Android_Debug_Bridge https://wiki.archlinux.org/title/Android_Debug_Bridge Gentoo https://wiki.gentoo.org/wiki/Android/adb https://wiki.gentoo.org/wiki/Android/adb ... And the adb option is in the docs with a description of what to do https://nixos.org/manual/nixos/stable/options#opt-programs.adb.enable https://nixos.org/manual/nixos/stable/options#opt-programs.a...
  - fallingsquirrel 2y ago
    Yes, I know that and you know that. But GP wanted to install the package and move on with his life instead of debugging a connection that failed with no indication why on an unfamiliar OS. https://search.nixos.org/packages?channel=24.05&show=android-tools&from=0&size=50&sort=relevance&type=packages&query=android-tools https://search.nixos.org/packages?channel=24.05&show=android... > How to install android-tools? > environment.systemPackages = [ pkgs.android-tools ]; How was he supposed to know to ignore those instructions and go to a completely different set of docs and search for "programs.adb.enable"? Instead he gave up and switched to another distro where you install the package and it Just Works™. Even though NixOS's model is conceptually better, it loses out on tons of potential users because of usability problems like this. (I'm running NixOS btw)
    - viraptor 2y ago
      Sometimes you just need to put in some work and understand what you're doing. The author needed to search for "adb" in the docs, not the whole attribute path. With the errors, they could debug the issue like they would on any other system. But that search is for packages themselves and is correct - that's how you install it. It's not going to tell you about the configuration just like it doesn't for nginx, postgresql, or many other packages. Sometimes you "have to be this high to ride", or use a simpler system - but that comes with its own issues. (Although in this very specific example it could just to make life easier - I'll send a PR next week unless someone does it first)
      - Arrowmaster 2y ago
        Why is this extra completion acceptable? On Debian I install the package adb and get the udev rules with it. I just need to connect a device and run adb commands.
        exe34 2y ago
        nixos is open source, I'm sure they'd welcome your proposed changes! they accept patches on GitHub.
        dqv 2y ago
        For the same reason that people get used to quirks on Debian (or any other distro really) that then eventually get fixed. Nobody's perfect, you live and you learn it. I use Hannah Montanix btw https://youtube.com/watch?v=2DQla5j26Qc https://youtube.com/watch?v=2DQla5j26Qc
        viraptor 2y ago
        Because nixos manages your system and nixpkgs only contains packages. Packages cannot do anything outside their installed location, so can't touch udev or groups to make the changes. There will be other apps split in the same way. The benefit is that just adding some package will never break your own configuration.
      - lostmsu 2y ago

spease 2y ago

I have tried to use it for C++, iOS, Python, Flutter, Docker, MacOS binaries, an Ubuntu container, MacOS, and NixOS. In every case it became a time sink that failed to work due to broken packages and convoluted code. Core issues are that: (1) To meet nix’s goal of declarative package management, everything in nix wraps software to create a bespoke interface for nix. But the documentation for the nix interface is extremely spotty and inconsistent, where it exists at all. (2) The language is a mix between functional and shell code, to create a declarative spec. This means many mental gear shifts while reading. This is made even worse by the nixpkgs API being inconsistent, with case-specific variants of functions (eg to set a property on a package you might need to call a language-specific property setter, which is very confusing when a package is built with multiple languages) (3) Many packages are broken or unsupported on one OS or the other. Because of these, it means that you need to be a coder AND have deep Linux knowledge AND deep Nix knowledge to use it for an extended period of time. And then: (4) Nix does not cleanly integrate with the packaging for a language, or expects running an AOT tool to generate a bespoke Nix derivation from the standard tooling I and others have complained about Nix being too difficult to use for years, but the Nix community instead is more excited about flakes, which are even more convoluted than existing derivations and metastasize the existing architectural issues in nixpkgs into countless decentralized packages that will now need to be refactored if someone tries to overhaul the design of nixpkgs. From my perspective, nix flakes are like if Linux was struggling with adoption because its internal and user APIs were undocumented and frequently broken, and the kernel developers got really excited about moving all the drivers out-of-tree into separate repositories because that’s “best practices”. A killer cross-platform and project / system package management system with hermetic build environments would be a godsend. But nix’s practical implementation of that is too badly done for me to have ever been able to use it for anything but the tiniest most specialized of projects, or as a partial package manager for macOS (where I still have to install things manually or use homebrew). There are a great many things that are theoretically possible with Nix, but I don’t know anything that I could practically recommend it for.

viraptor 2y ago
> Many packages are broken or unsupported on one OS or the other. Report them. There's thousands of packages. Efforts like Zero Hydra Fails help, but there's still a lot to fix. If you raise an issue, it will be prioritised, because we'll know someone actually cares about it. Keep in mind that's compared to a small percent of those packages available in other systems where you're on your own - not much different than on nixos with a broken package.