3 ms·

The language is small enough that there's no way it's a problem. It seems less complicated than YAML, a couple hours to pick up at most. I have a NixOS setup o

The language is small enough that there's no way it's a problem. It seems less complicated than YAML, a couple hours to pick up at most. I have a NixOS setup on my desktop and use Nix for some projects, but only maybe a week or two of experience. And the language was never an issue. The bigger problem is the standard library is a sprawling mess: Understanding what options are available or how to get your thing to build by analogy with someone else's, requires digging into nixpkgs with no good tool support. If you did a line-by-line port from Nix to YAML or Python but kept the standard library exactly the same, it would be even harder to understand.

takeda 5y ago
Yes, nixpkgs desperately needs to be split, at least into two packages: - stdlib - packages The stdlib could also include builders and language frameworks, or they could be split even further. Then treat the stdlib the same way as it is treated in any other language (make it stable, not changed frequently and make sure everything is documented with the release). That would reduce the need of reading source code to use nix.
- Ericson2314 5y ago
  I am not so sure about that. Nixpkgs is a big ball because it is the final integration point. And I do in fact find myself refactoring individual packages and the infra at the same time. https://github.com/NixOS/rfcs/pull/109/ https://github.com/NixOS/rfcs/pull/109/ I wrote to hopefully make the lang2nix packages work with Nixpkgs. I think this would achieve most of the benefits of what you propose: cleaner separation of infra vs vs ad-hoc per-package stuff, while still retaining the flexibility of the monorepo. The goal is to work with upstream developers so less and less ad-hoc crap is needed. Then the one repo ends up "all stdlib no packages", because the packages are basically autogenerated!
  - takeda 5y ago
    I have mixed opinion about this. I mean, I understand that there are increasingly applications that are getting harder and harder to package, but if there are tools that could just parse lock files and build a project without any work, in that case why even package it, one could just have function where we could point to SCM repo and it would fetch and install the application. I'm still not fully understanding what import from derivation really mean (technically) is it an ability to fetch the source from repos during evaluation? If so, that is an issue. If one tries to use Nix in environment with repos that require authentication it is a huge pain. There was a workaround once with passing SSH configuration, but it was removed. I also think your RFC is orthogonal to what I suggested. I think #1 issue with Nix is steep learning curve, and huge part of it is documentation that is not up to date. The thing is, as others said, Nix is great when everything works, as soon as you step into something that's not as common suddenly things become really complex, because documentation is not enough, one has to dive into nixpkgs which is very complex. > Nixpkgs is a big ball because it is the final integration point. And I do in fact find myself refactoring individual packages and the infra at the same time. That's actually the problem I'm talking about. Because this infrastructure code is constantly changing => that makes the documentation be not up to date => makes Nix more difficult for others to start using it. You don't have difficulty with it because you know it inside and out, I know enough to usually find what I'm looking for, but from my own experience I remember it was really hard to get to the point where I'm and I'm still not that great at it. Normally if that was happening in any other language it would be considered to be not ready yet for wide use, but Nix does want to be used and think this is one of things needed. Even with up to date documentation it there are still difficult things, but at least it would be huge improvement. Imagine if Go or Python sdk was not up to date and the way to learn it would be studying sdk's source code. It would be a drastically different programming experience and I doubt people would call those languages beginner friendly.

takeda 5y ago

Yes, nixpkgs desperately needs to be split, at least into two packages: - stdlib - packages The stdlib could also include builders and language frameworks, or they could be split even further. Then treat the stdlib the same way as it is treated in any other language (make it stable, not changed frequently and make sure everything is documented with the release). That would reduce the need of reading source code to use nix.

Ericson2314 5y ago
I am not so sure about that. Nixpkgs is a big ball because it is the final integration point. And I do in fact find myself refactoring individual packages and the infra at the same time. https://github.com/NixOS/rfcs/pull/109/ https://github.com/NixOS/rfcs/pull/109/ I wrote to hopefully make the lang2nix packages work with Nixpkgs. I think this would achieve most of the benefits of what you propose: cleaner separation of infra vs vs ad-hoc per-package stuff, while still retaining the flexibility of the monorepo. The goal is to work with upstream developers so less and less ad-hoc crap is needed. Then the one repo ends up "all stdlib no packages", because the packages are basically autogenerated!
- takeda 5y ago
  I have mixed opinion about this. I mean, I understand that there are increasingly applications that are getting harder and harder to package, but if there are tools that could just parse lock files and build a project without any work, in that case why even package it, one could just have function where we could point to SCM repo and it would fetch and install the application. I'm still not fully understanding what import from derivation really mean (technically) is it an ability to fetch the source from repos during evaluation? If so, that is an issue. If one tries to use Nix in environment with repos that require authentication it is a huge pain. There was a workaround once with passing SSH configuration, but it was removed. I also think your RFC is orthogonal to what I suggested. I think #1 issue with Nix is steep learning curve, and huge part of it is documentation that is not up to date. The thing is, as others said, Nix is great when everything works, as soon as you step into something that's not as common suddenly things become really complex, because documentation is not enough, one has to dive into nixpkgs which is very complex. > Nixpkgs is a big ball because it is the final integration point. And I do in fact find myself refactoring individual packages and the infra at the same time. That's actually the problem I'm talking about. Because this infrastructure code is constantly changing => that makes the documentation be not up to date => makes Nix more difficult for others to start using it. You don't have difficulty with it because you know it inside and out, I know enough to usually find what I'm looking for, but from my own experience I remember it was really hard to get to the point where I'm and I'm still not that great at it. Normally if that was happening in any other language it would be considered to be not ready yet for wide use, but Nix does want to be used and think this is one of things needed. Even with up to date documentation it there are still difficult things, but at least it would be huge improvement. Imagine if Go or Python sdk was not up to date and the way to learn it would be studying sdk's source code. It would be a drastically different programming experience and I doubt people would call those languages beginner friendly.