5 ms·

I think the idea is good but execution is poor to reach mass adoption because: 1. It tries to replace ALL package managers due its extreme philosophy. I had a

by baby 3y ago

I think the idea is good but execution is poor to reach mass adoption because: 1. It tries to replace ALL package managers due its extreme philosophy. I had a lot of issues when it tries to replace Cargo for example 2. It uses a functional language, which will lose 95% of users 3. It never had a great user experience especially if you’re new and trying to learn or if you’re not using linux or if you bring your own tools (e.g. vscode) I think something like that could totally exist one day, but it’ll have to restart from scratch on a cleaner base IMO

colordrops 3y ago
What exactly would this "cleaner base" look like? A main goal of Nix is a completely reproducible deployment, and many tools are not built for declarative usage, so Nix must add a layer on top in order to make them declarative. If you only go part way, then the entire point of Nix is nullified. Might as well use Ansible. That being said, it's really not that difficult to use tools in their original form on Nix is you want. You can create temporary FHS shells in which tools just work. I do this with Python, as I can't be bothered to do it the "right" way when I just want to run some random script from github.
- baby 3y ago
  My experience with Nix is that my own tools didn't work, even with the help of Nix experts. Then, after months of debugging we figured out that I had to quit vscode completely, and then start it from the console using the nix command with the -i option to clean up any environment variable (without that option it wouldn't work). There were some nix plugins for vscode, which would have been awesome if they had worked, but they didn't.
- cstrahan 3y ago
  > What exactly would this "cleaner base" look like? My interpretation would be something like: the abandonment of software that is so poorly designed that it is difficult to package and/or run under Nix. This commit message (from one of my commits) details some of the struggles supporting Ruby under Nix: https://github.com/NixOS/nixpkgs/commit/b6c06e216bb3bface40eb8ea6576b25f9b2971dd https://github.com/NixOS/nixpkgs/commit/b6c06e216bb3bface40e... Each of those problems is due to either: 1. Some unmotivated contrivance in Bundler, where the maintainers refused to make their stuff less needlessly broken, or 2. Ruby programmers in general not programming with packaging in mind (haven't touched Ruby/Rails professionally in a while, but when I did, it was par for the course to rsync/capistrano files around -- no one saw the utility of any sort of packaging) And the two really reinforce each other. Bundler is the de facto way to declare and pin dependencies at the app level, but then Bundler makes it nearly impossible (see the commit message for details) to package software using Bundler, which reinforces the "fuck it, we'll just rsync files around over SSH", which means no one pressures Bundler to Do The Right Thing. It's the same thing everywhere else. There are complaints elsewhere in this comment section about the nodejs/npm experience on Nix: same underlying problem. The design behind npm is so unnecessarily shit-tacular that it kinda sorta just barely works on its tier 1 platforms. I don't envy the brave souls that have worked on supporting npm packages on Nix.
  - colordrops 3y ago
    The Nix community can try to boil the ocean, or they can create a platform that can be a stepping stone to better things. With the recent upswing in Nix usage, many new systems and packages are built with Nix and Nix-like declarative systems in mind. It's a positive feedback loop. It's not possible to rebuild literally everything from scratch to work in the "nix way", so older systems are supported with a wrapper layer, and newer ones should hopefully work in a more natural way. Guix and Hurd and whatnot try to be more pure about things and look how far it got them. There are tens of thousands of projects that would basically need to be redesigned and written from the ground up to achieve what you desire, and I think the best approach is to build the platform and prove its value and create a path and model for new projects to follow. There are only so many open source developers out there.
    - cstrahan 3y ago
      I agree with all of the above. And I just realized: I should probably clarify what I meant when I suggested "the abandonment of software that is so poorly designed that it is difficult to package and/or run under Nix" as the means for a "cleaner base". While that would make things cleaner in some sense, it's not what I'm suggesting Nix should do. I was mostly trying to clarify that the majority of what needs cleaning is extrinsic, rather than some intrinsic failing of Nix itself (though things could certainly be improved there, too). The greatest source of difficulty for packaging/running things under Nix (having contributed at least a couple dozen packages, and the entirety of the Ruby/Bundler support) is software violating well established principles. To pick one silly example: say you need to get the home directory for the current user. Yes, you could do the equivalent of "/home/${USER}", and while that might coincidentally work on 99.999% systems, that's still wrong -- there's nothing keeping someone from having their home dir be something arbitrary like "/home_is_where_the_heart_is", and now your software will break. The funny thing is that the right way to handle this is also the easy way: use "${HOME}" if it exists, and failing that, fall back to `getpwuid` (or whatever your language calls it). It's easier/simpler because you no longer need to make any assumptions about how the file system is laid out -- either the user tells you through $HOME or you consult the password entry. Easy. But what happens when you send a pull request to fix the objectively wrong logic of the first example? You get push back saying "well, it works on my machine, and this is the first complaint we've heard, so no, I don't think I'll merge your request". So, I guess I'm being kind of roundabout, but the takeaway I'd like for everyone to have is this: if working with your programming language is difficult on Nix, please go look for (and upvote) open issues in your language's issue tracker (they're probably there) from other Nix maintainers begging for fixes that would not only make it easier for Nix users, but would also remove latent correctness problems that have gone unnoticed solely due to the coincidental uniformity of all other commonly used distros. Just because something works everywhere other than Nix doesn't mean that the code in question isn't needlessly complicated/fragile and/or dependent on non-standardized assumptions that just so happen to be common on other systems.
mikercampbell 3y ago
This is why I come to the comments. I’ve encountered NixOS through Replit and thought it was such a fantastic way to manage environments, when I’m using things like ASDF and Bash scripts for installs, I’d love this. Then comes the question “I won’t commit to something like this and I don’t know why”, and you just articulated it for me.
duped 3y ago
I don't think points 1 and 2 are really that valid, but 3 is why I'm a Nix hater. They've managed to design an arcane solution to an everyday problem. Nix solves real problems that Cargo can't/won't. And the 95% use case worth optimizing for isn't someone authoring flakes, but people just looking for the proper incantation to get the software they need for their environment.
tkz1312 3y ago
nix is so powerful precisely because it takes a pure functional approach. You don’t get that level of reproducibility if you allow side effects.
- gcommer 3y ago
  Avoiding side effects does not require inventing a brand new purely functional language programming language.
  - deleted 3y ago
    [deleted]
  - tkz1312 3y ago
    That’s true to an extent. It’s possible to define nix packages in impure languages, but those languages are still compiling down to package definitions (.drv files) that are purely declarative and are executed in an environment that forbids any side effects. So it’s more a question of whether it’s a nicer experience to wrap up a pure core in some impure outer layer, or just make the whole thing pure. Nix the language is imo pretty nice for what it does, and lots of other config languages seem to have ended up in similar kind of “json with functions” part of the design space (e.g. dhall, jsonnet). My personal view is that purity in the nix language helps more than it hurts, and that the big design fuckup wasn’t writing a custom DSL, but writing a custom DSL without static types.
  - duped 3y ago
    Is your issue with the fact the language is functional, or that it's a DSL specific to Nix?
  - lproven 3y ago
    > inventing a brand new purely functional language programming language. ISTM that if you dislike that, then there's GUIX. https://guix.gnu.org/ https://guix.gnu.org/ Very briefly, AFAICT, it's "Nix but using Scheme".
    - 3y ago
bmitc 3y ago
I need to do some reading up on Nix, because I don't think I understand it. I thought NixOS was an operating system and Nix an operating system-level package manager, so why is it trying to replace Cargo, a package manager for a specific programming language in Rust?
- from-nibly 3y ago
  Because nix is also the build tool that the packages are built with.
- mid-kid 3y ago
  For the same reason debian's APT manages rust dependencies for its packages - an OS-level package manager needs to support all its languages. Language-specific package managers fall short as they don't (and often can't) consider cross-language dependencies.
- cstrahan 3y ago
  The same reason Bazel builds avoid using Cargo when building Rust software, so I'll describe why Bazel would do this: - Bazel wants to cache remote resources, like each respective crate's source files. - Bazel then wants to build each crate in a sandbox, and cache the build artifacts. Because bazel owns this process, instead of Cargo, it can trivially distribute those build artifacts to other developers, or in CI, etc -- instead of everyone having to build everything from scratch. This is an established practice, and Nix wants to drive the build for the same reasons. See: - https://github.com/bazelbuild/rules_rust https://github.com/bazelbuild/rules_rust - https://github.com/google/cargo-raze https://github.com/google/cargo-raze
jljljl 3y ago
If you don't want to fully commit to the OS or the Package Manager, you can use Nixpkgs alongside your OS and other package managers by installing Nixpkgs on your Mac or Linux OS. For the functional language and UX, I agree there's room for improvement. If you don't want to dive into learning Nix, you could use a wrapper that simplifies the UX for creating projects. We built one called Devbox (https://jetpack.io/devbox https://jetpack.io/devbox), which uses JSON for it's config format and has a CLI inspired by more familiar tools like Yarn.

by baby 3y ago

colordrops 3y ago

What exactly would this "cleaner base" look like? A main goal of Nix is a completely reproducible deployment, and many tools are not built for declarative usage, so Nix must add a layer on top in order to make them declarative. If you only go part way, then the entire point of Nix is nullified. Might as well use Ansible. That being said, it's really not that difficult to use tools in their original form on Nix is you want. You can create temporary FHS shells in which tools just work. I do this with Python, as I can't be bothered to do it the "right" way when I just want to run some random script from github.

baby 3y ago
My experience with Nix is that my own tools didn't work, even with the help of Nix experts. Then, after months of debugging we figured out that I had to quit vscode completely, and then start it from the console using the nix command with the -i option to clean up any environment variable (without that option it wouldn't work). There were some nix plugins for vscode, which would have been awesome if they had worked, but they didn't.
cstrahan 3y ago
> What exactly would this "cleaner base" look like? My interpretation would be something like: the abandonment of software that is so poorly designed that it is difficult to package and/or run under Nix. This commit message (from one of my commits) details some of the struggles supporting Ruby under Nix: https://github.com/NixOS/nixpkgs/commit/b6c06e216bb3bface40eb8ea6576b25f9b2971dd https://github.com/NixOS/nixpkgs/commit/b6c06e216bb3bface40e... Each of those problems is due to either: 1. Some unmotivated contrivance in Bundler, where the maintainers refused to make their stuff less needlessly broken, or 2. Ruby programmers in general not programming with packaging in mind (haven't touched Ruby/Rails professionally in a while, but when I did, it was par for the course to rsync/capistrano files around -- no one saw the utility of any sort of packaging) And the two really reinforce each other. Bundler is the de facto way to declare and pin dependencies at the app level, but then Bundler makes it nearly impossible (see the commit message for details) to package software using Bundler, which reinforces the "fuck it, we'll just rsync files around over SSH", which means no one pressures Bundler to Do The Right Thing. It's the same thing everywhere else. There are complaints elsewhere in this comment section about the nodejs/npm experience on Nix: same underlying problem. The design behind npm is so unnecessarily shit-tacular that it kinda sorta just barely works on its tier 1 platforms. I don't envy the brave souls that have worked on supporting npm packages on Nix.
- colordrops 3y ago
  The Nix community can try to boil the ocean, or they can create a platform that can be a stepping stone to better things. With the recent upswing in Nix usage, many new systems and packages are built with Nix and Nix-like declarative systems in mind. It's a positive feedback loop. It's not possible to rebuild literally everything from scratch to work in the "nix way", so older systems are supported with a wrapper layer, and newer ones should hopefully work in a more natural way. Guix and Hurd and whatnot try to be more pure about things and look how far it got them. There are tens of thousands of projects that would basically need to be redesigned and written from the ground up to achieve what you desire, and I think the best approach is to build the platform and prove its value and create a path and model for new projects to follow. There are only so many open source developers out there.
  - cstrahan 3y ago
    I agree with all of the above. And I just realized: I should probably clarify what I meant when I suggested "the abandonment of software that is so poorly designed that it is difficult to package and/or run under Nix" as the means for a "cleaner base". While that would make things cleaner in some sense, it's not what I'm suggesting Nix should do. I was mostly trying to clarify that the majority of what needs cleaning is extrinsic, rather than some intrinsic failing of Nix itself (though things could certainly be improved there, too). The greatest source of difficulty for packaging/running things under Nix (having contributed at least a couple dozen packages, and the entirety of the Ruby/Bundler support) is software violating well established principles. To pick one silly example: say you need to get the home directory for the current user. Yes, you could do the equivalent of "/home/${USER}", and while that might coincidentally work on 99.999% systems, that's still wrong -- there's nothing keeping someone from having their home dir be something arbitrary like "/home_is_where_the_heart_is", and now your software will break. The funny thing is that the right way to handle this is also the easy way: use "${HOME}" if it exists, and failing that, fall back to `getpwuid` (or whatever your language calls it). It's easier/simpler because you no longer need to make any assumptions about how the file system is laid out -- either the user tells you through $HOME or you consult the password entry. Easy. But what happens when you send a pull request to fix the objectively wrong logic of the first example? You get push back saying "well, it works on my machine, and this is the first complaint we've heard, so no, I don't think I'll merge your request". So, I guess I'm being kind of roundabout, but the takeaway I'd like for everyone to have is this: if working with your programming language is difficult on Nix, please go look for (and upvote) open issues in your language's issue tracker (they're probably there) from other Nix maintainers begging for fixes that would not only make it easier for Nix users, but would also remove latent correctness problems that have gone unnoticed solely due to the coincidental uniformity of all other commonly used distros. Just because something works everywhere other than Nix doesn't mean that the code in question isn't needlessly complicated/fragile and/or dependent on non-standardized assumptions that just so happen to be common on other systems.

mikercampbell 3y ago

This is why I come to the comments. I’ve encountered NixOS through Replit and thought it was such a fantastic way to manage environments, when I’m using things like ASDF and Bash scripts for installs, I’d love this. Then comes the question “I won’t commit to something like this and I don’t know why”, and you just articulated it for me.

duped 3y ago

I don't think points 1 and 2 are really that valid, but 3 is why I'm a Nix hater. They've managed to design an arcane solution to an everyday problem. Nix solves real problems that Cargo can't/won't. And the 95% use case worth optimizing for isn't someone authoring flakes, but people just looking for the proper incantation to get the software they need for their environment.

tkz1312 3y ago

nix is so powerful precisely because it takes a pure functional approach. You don’t get that level of reproducibility if you allow side effects.

gcommer 3y ago
Avoiding side effects does not require inventing a brand new purely functional language programming language.
- deleted 3y ago
  [deleted]
- tkz1312 3y ago
  That’s true to an extent. It’s possible to define nix packages in impure languages, but those languages are still compiling down to package definitions (.drv files) that are purely declarative and are executed in an environment that forbids any side effects. So it’s more a question of whether it’s a nicer experience to wrap up a pure core in some impure outer layer, or just make the whole thing pure. Nix the language is imo pretty nice for what it does, and lots of other config languages seem to have ended up in similar kind of “json with functions” part of the design space (e.g. dhall, jsonnet). My personal view is that purity in the nix language helps more than it hurts, and that the big design fuckup wasn’t writing a custom DSL, but writing a custom DSL without static types.
- duped 3y ago
  Is your issue with the fact the language is functional, or that it's a DSL specific to Nix?
- lproven 3y ago
  > inventing a brand new purely functional language programming language. ISTM that if you dislike that, then there's GUIX. https://guix.gnu.org/ https://guix.gnu.org/ Very briefly, AFAICT, it's "Nix but using Scheme".
  - 3y ago

bmitc 3y ago

I need to do some reading up on Nix, because I don't think I understand it. I thought NixOS was an operating system and Nix an operating system-level package manager, so why is it trying to replace Cargo, a package manager for a specific programming language in Rust?

from-nibly 3y ago
Because nix is also the build tool that the packages are built with.
mid-kid 3y ago
For the same reason debian's APT manages rust dependencies for its packages - an OS-level package manager needs to support all its languages. Language-specific package managers fall short as they don't (and often can't) consider cross-language dependencies.
cstrahan 3y ago
The same reason Bazel builds avoid using Cargo when building Rust software, so I'll describe why Bazel would do this: - Bazel wants to cache remote resources, like each respective crate's source files. - Bazel then wants to build each crate in a sandbox, and cache the build artifacts. Because bazel owns this process, instead of Cargo, it can trivially distribute those build artifacts to other developers, or in CI, etc -- instead of everyone having to build everything from scratch. This is an established practice, and Nix wants to drive the build for the same reasons. See: - https://github.com/bazelbuild/rules_rust https://github.com/bazelbuild/rules_rust - https://github.com/google/cargo-raze https://github.com/google/cargo-raze

jljljl 3y ago

If you don't want to fully commit to the OS or the Package Manager, you can use Nixpkgs alongside your OS and other package managers by installing Nixpkgs on your Mac or Linux OS. For the functional language and UX, I agree there's room for improvement. If you don't want to dive into learning Nix, you could use a wrapper that simplifies the UX for creating projects. We built one called Devbox (https://jetpack.io/devbox https://jetpack.io/devbox), which uses JSON for it's config format and has a CLI inspired by more familiar tools like Yarn.