Move `lib` to a separate repository
> [!Important] > This is a long thread, so before making a comment, please read the full proposal and discussion, and only post what hasn't been brought up before. Thanks! I've previously suggested this [on Discourse](https://discourse.nixos.org/t/monorepos-dont-map-to-our-social-structure/44162/12) (and again [here](https://discourse.nixos.org/t/any-interest-in-separating-out-nixpkgs-lib-into-its-own-repo-flake/39374/4)), which has garnered a surprising number of likes, so let's consider this! Here's a first draft proposal to discuss ## Motivation `lib` (note: not everything, see the plan below) is arguably the most independent part of Nixpkgs, it has effectively no dependency on anything other than itself (and Nix) and virtually no PRs touch both `lib` and non-`lib` (which is also in the [lib PR guidelines](https://github.com/NixOS/nixpkgs/tree/master/lib#pr-guidelines)). - The vast majority of Nixpkgs issues and PRs are unrelated to `lib`, which makes `lib` development hard to track. Yes there's [a label](https://github.com/NixOS/nixpkgs/pulls?q=%226.topic%3A+lib%22), but e.g. people can't just watch the entire repo. - Also, the label can't be applied to issues automatically. - Having a separate repo allows more granular repo permissions (though for the start let's keep the status quo) - A separate repo allows avoiding the dependency on the rest of Nixpkgs for those who don't need it. - Although this point is kind of moot, because https://github.com/nix-community
Posted by infinisil on Feb 13, 2025, 9:31 PM
Tags
Related issues
- This is the biggest problem with contracts, there's simply no way to actually say "please always execute this check".
- I don't disagree with you on this, I worked my whole life in corporate and haven't worked as a OSS maintainer before, though I will _and ...
- the new VSCode UI, looks cute, i don't like it.
- I've been working on my own private harness for the past 8 months, and I've been collecting ideas from such repos I've stumbled upon.
- The way AI is able to interact with outside resources is pretty impressive, but the quality of code it produces to me is still questionab...
- Add PR-style review comments in Git Diff UI that feed into the active agent thread
Raise real-world problems, find people facing the same issue, and discuss solutions.2,000 issues0 comments
ux (Software)
This is the biggest problem with contracts, there's simply no way to actually say "please always execute this check".
I don't disagree with you on this, I worked my whole life in corporate and haven't worked as a OSS maintainer before, though I will _and ...
the new VSCode UI, looks cute, i don't like it.
I've been working on my own private harness for the past 8 months, and I've been collecting ideas from such repos I've stumbled upon.
The way AI is able to interact with outside resources is pretty impressive, but the quality of code it produces to me is still questionab...
Add PR-style review comments in Git Diff UI that feed into the active agent thread
Thanks for indulging me so far, by the way, I really appreciate this discussion, it's very stimulating.
Migrate GDScript to the GDExtension mechanism and overhaul the implementation
Move `lib` to a separate repository
> [!Important] > This is a long thread, so before making a comment, please read the full proposal and discussion, and only post what hasn't been brought up before. Thanks! I've previously suggested this [on Discourse](https://discourse.nixos.org/t/monorepos-dont-map-to-our-social-structure/44162/12) (and again [here](https://discourse.nixos.org/t/any-interest-in-separating-out-nixpkgs-lib-into-its-own-repo-flake/39374/4)), which has garnered a surprising number of likes, so let's consider this! Here's a first draft proposal to discuss ## Motivation `lib` (note: not everything, see the plan below) is arguably the most independent part of Nixpkgs, it has effectively no dependency on anything other than itself (and Nix) and virtually no PRs touch both `lib` and non-`lib` (which is also in the [lib PR guidelines](https://github.com/NixOS/nixpkgs/tree/master/lib#pr-guidelines)). - The vast majority of Nixpkgs issues and PRs are unrelated to `lib`, which makes `lib` development hard to track. Yes there's [a label](https://github.com/NixOS/nixpkgs/pulls?q=%226.topic%3A+lib%22), but e.g. people can't just watch the entire repo. - Also, the label can't be applied to issues automatically. - Having a separate repo allows more granular repo permissions (though for the start let's keep the status quo) - A separate repo allows avoiding the dependency on the rest of Nixpkgs for those who don't need it. - Although this point is kind of moot, because https://github.com/nix-community
Comments (0)
No comments yet. Start the discussion.