You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository has been archived by the owner on Jan 30, 2023. It is now read-only.
I want to start this by saying I am rooting for this RFC to be successful. I like that idea of "just throw a file in this directory, and we'll take care of the rest".
I have some questions to ask.
How third party overlays and other initiatives will be affected by this proposal?
Certainly Nix allows a pretty much free-form overlay. However, there is an expectation that the Nixpkgs code layout inspires the maintainers of overlays, acting as a template.
Also, an overlay with a similar layout can be merged upstream more easily; indeed this is an interesting workflow for adding packages to Nixpkgs.
That being said, what will a third party overlay maintainer be affected by this RFM?
Can they use this new pkgs/unit/<dir/list>/pkg-fun.nix layout and automagically everything will work?
The old default.nix + all-packages.nix will fail for them too?
Thanks, and apologies for the bad formatting.
The text was updated successfully, but these errors were encountered:
This RFC doesn't affect the (public) nixpkgs interface at all, all third-party overlays and other code interacting with nixpkgs will continue working the same. One exception is when the third-party code depends on the internal layout of files in nixpkgs, in which case moving around those files (or even changing them) will break that third-party code.
This in particular is also a focus of this RFC, to make it clear that the file layout of nixpkgs is in general not a public interface, to avoid getting locked into having to keep the same file structure forever and being able to make more treewide changes.
However, you're right that a structure like this will probably inspire other people to want something similar in third-party code. While we do plan to eventually make this unit directory structure an actual standard for third-party use, for now we just want to see how it works internally in nixpkgs before that. This way if it turns out that it needs some changes, we can still easily change it by just making a tree-wide nixpkgs update and don't have to worry about third-parties who also adopted this structure. Definitely something we want in the future though.
I do think we should make that clearer in the RFC text :)
Can they use this new pkgs/unit/<dir/list>/pkg-fun.nix layout and automagically everything will work?
The old default.nix + all-packages.nix will fail for them too?
Note that nixpkgs currently has no way of being composed with other nixpkgs-like directories. There's no code in nixpkgs that would import a pkgs directory or an all-packages.nix file. For now the only public interface nixpkgs has for being composed with other packages is the overlays interface, which is unaffected by this RFC. You might be thinking of ~/.config/nixpkgs/overlays though, which allows you to specify overlays that are imported automatically.
Sign up for freeto subscribe to this conversation on GitHub.
Already have an account?
Sign in.
Hello!
I want to start this by saying I am rooting for this RFC to be successful. I like that idea of "just throw a file in this directory, and we'll take care of the rest".
I have some questions to ask.
Certainly Nix allows a pretty much free-form overlay. However, there is an expectation that the Nixpkgs code layout inspires the maintainers of overlays, acting as a template.
Also, an overlay with a similar layout can be merged upstream more easily; indeed this is an interesting workflow for adding packages to Nixpkgs.
That being said, what will a third party overlay maintainer be affected by this RFM?
Can they use this new
pkgs/unit/<dir/list>/pkg-fun.nix
layout and automagically everything will work?The old
default.nix + all-packages.nix
will fail for them too?Thanks, and apologies for the bad formatting.
The text was updated successfully, but these errors were encountered: