In reply to @blaggacao:matrix.org
bud is a functor.

Hey everyone! I have recently decided to give devos a try and started converting my pre-existing NixOS configuration to its format and I have a couple of doubts that I couldn't solve through the documentation and I'd like to confirm with you:

1. Is it possible to remove inputs from the main flake.nix? Specifically, I'd like to remove nixos-hardware, since I won't use it (as there's nothing relevant there for my use case). Is it just a matter of removing the input itself or is there a more involved process?
2. From nxdxp's config I gathered that it's possible to split option declarations throughout different files and it all gets merged (for instance, several environment.systemPackages declarations in different files), but does this apply everywhere? Are there any special considerations to be had (exceptions, edge cases, etc. that I need to be wary of)?

Thanks in advance for the work put into this project!

Hii! I'm glad your trying devos out.

1. Yes removing inputs is pretty simple, you remove the line in the inputs at the top and the line where the input is used. For nixos-hardware, its actually not used anywhere in devos by default(I think) so you should just be able to remove the input line.
2. Thats actually a feature of the nixpkgs module system. options can be defined in multiple files - the technical term is different modules - and they get merged. options that are list, like systemPackages, will get appended. You can learn more about nixos module system in it's manual.

Hii! I'm glad your trying devos out.

1. Yes removing inputs is pretty simple, you remove the line in the inputs at the top and the line where the input is used. For nixos-hardware, its actually not used anywhere in devos by default(I think) so you should just be able to remove the input line.
2. Thats actually a feature of the nixpkgs module system. options can be defined in multiple files - the technical term is module - and they get merged. options that are list, like systemPackages, will get appended. You can learn more about nixos module system in it's manual.

In reply to @fufexan:matrix.org
is there any way in fup to remove a channel?

what's the current suggested way for adding new packages which are already defined in some external flake?

the docs in develop for pkgs seem to be out of date, but the nvfetcher docs seem to suggest adding it to sources.toml then defining an overlay as is done with manix, to override pname, version and src

I tried doing this with rnix-lsp, which I can build fine if I separately clone it, but if I just follow the same override syntax as manix I get a cargoSha256 error.

I'm guessing this is overall not the correct way to do this, does anyone have some suggestions?

In reply to @kraftnix:matrix.org

what's the current suggested way for adding new packages which are already defined in some external flake?

the docs in develop for pkgs seem to be out of date, but the nvfetcher docs seem to suggest adding it to sources.toml then defining an overlay as is done with manix, to override pname, version and src

I tried doing this with rnix-lsp, which I can build fine if I separately clone it, but if I just follow the same override syntax as manix I get a cargoSha256 error.

I'm guessing this is overall not the correct way to do this, does anyone have some suggestions?

There are two ways: nixpkgs's overlays or flake's follows. With the follows-way you bet on memoizing the nixpkgs evaluation that a certain package requires to build. Memoization works if the import call signature of nixpkgs is equal, for example import nixpkgs { config = {}; overlays = [];} With the overlays way, you "patch" external instructions into the pkgs namespace. This is why pkgs.addOVerlay or pkgs.extend do a full re-evaluation of the entire pkgs namespace to calculate a new fixed-point (taking into account the added packages).

sources, on the other hand is itself an overlay that adds the pkgs.sources namespace that holds reference to a source's package name, sourcecode and version information.