In order to reduce the build time, it seems to be necessary to omit and block unused packages from the contents of all-package.nix so that only the software used among the packages of nixpkgs can be parsed as options like nix build —omit-parse-unuse. we no necessery all nixpkgs,
What do you think?
And Internally, the dynamic “nix store & nixpkgs parsing db?” is so slow when build.
So, when parsing and checking the previous installation list and the current nix setup code,
As if there is no derivation of packages that are not installed at all, dynamic caching or dynamic override code generation must be done internally to save time.
Another solution is to provide new micro nixpkgs or void nixpkgs in the flake entry point,
Flake has already been created and we’ve been using it for several years, but I think one important thing missing from the nix community is the omit problem. There seems to be a need for an official new installation method that will significantly reduce the more reliable installation time.
So the current nixpkgs repository, we will use exclusively as a package derivation repository. -.,- nixpkgs that’s very big… my computer so sick. My computer very overheating and is about to explode.
This method is the answer, but…
Are buildings unavoidable in global installations?
nix run github:nixos/nixpkgs/22.05#python310
nix run github:nixos/nixpkgs/22.05#emacs
nix run github:nixos/nixpkgs/22.05#blender
nix run github:nixos/nixpkgs/22.05#git
I haven’t tried writing my own flakes yet, but I wish there was a way to interact with each other (including custom flakes). Already internally, common packages seem to be able to reduce the build, but should I have to use shell.nix for wrapping?
I am still very satisfied.
It seems that, are already working on something similar to our intention.
Looks like I need this too.
We need something sexy. When creating flakes, for example, things like making flake.nix file creation easier by merging needs together.