In reply to @blaggacao:matrix.org

At work I learned that the issues with follows inputs are not completely gone and that the only really effective way to deal with it (for now) is to reduce & push to the leave:

• reduce -> don't bother about non-nixpkgs, since they are usually libs, are small and don't have huge deps themselves
• push to the leaf -> make it a responsability of the end user flake. (Almost) all follows issues that I still hace seen with recent versions could be resolve when the follows statements are used at the leaf.

In reply to @blaggacao:matrix.org
At this point, my current best advice to reduce closure size is to fare with a balanced approch: deduplicate the core blobs like nixpkgs and make sure you don't have largely duplicated dep trees, but don't care too much about leaf packages with only a few runtime deps & don't care at all about pure nix libraries.

In reply to @blaggacao:matrix.org
Btw, I kicked bud out of my own env, since I really like the uniformity that deploy-rs provides for the current use cases of bud.

In reply to @blaggacao:matrix.org
Yeah, the repl is a good workflow aide, but since newer nix has :lf . part of it is also superfluous. I kind of feel that a zoxide-based workflow that quickly drops you into the flake repo on any machine is just as handy & also leaves you in the fs-context that you'll be operating on.

In reply to @blaggacao:matrix.org
Although it works with a small patch on my end, we really need to make nix profile respect meta.priority. since co-existence of nix & nix-zsh-completions depend on it.

In reply to @kraftnix:matrix.org
oh wow, I was not aware of :lf ., that is so much more convenient than Flake = builtins.getFlake "full/path/to/flake, is there a way to have :lf add the flake to a specific scope (to somewhat emulate Flake = builtins.getFlake ... ?

In reply to @kraftnix:matrix.org
are there some issues with nix and nix-zsh-completions? back around september there were some changes and since then i've had nix work pretty perfectly in zsh with autocompletions.

|reduce -> don't bother about non-nixpkgs, since they are usually libs, are small and don't have huge deps themselves
push to the leaf -> make it a responsability of the end user flake. (Almost) all follows issues that I still hace seen with recent versions could be resolve when the follows statements are used at the leaf.

On this, I've always favored reduce. I think cargo and npm style package managers follow this. Each dependency is needed at different versions and its not much of a cost to just pull required dependencies even if its redundant. I only see a problem with this method when nixpkgs is an input and only because of how large nixpkgs currently is.
This was where my objection to the extra follows use came from for digga.

reduce -> don't bother about non-nixpkgs, since they are usually libs, are small and don't have huge deps themselves
push to the leaf -> make it a responsability of the end user flake. (Almost) all follows issues that I still hace seen with recent versions could be resolve when the follows statements are used at the leaf.

On this, I've always favored reduce. I think cargo and npm style package managers follow this. Each dependency is needed at different versions and its not much of a cost to just pull required dependencies even if its redundant. I only see a problem with this method when nixpkgs is an input and only because of how large nixpkgs currently is.
This was where my objection to the extra follows use came from for digga.

In reply to @pachumicchu:myrdd.info

reduce -> don't bother about non-nixpkgs, since they are usually libs, are small and don't have huge deps themselves
push to the leaf -> make it a responsability of the end user flake. (Almost) all follows issues that I still hace seen with recent versions could be resolve when the follows statements are used at the leaf.

On this, I've always favored reduce. I think cargo and npm style package managers follow this. Each dependency is needed at different versions and its not much of a cost to just pull required dependencies even if its redundant. I only see a problem with this method when nixpkgs is an input and only because of how large nixpkgs currently is.
This was where my objection to the extra follows use came from for digga.

yeah, I actually wanted to follow this method, but in the end I had to hard follow every single input of every flake I used, due to what I can only imagine is a new bug.

I started getting some extremely strange handling differences between nix develop/direnv and nix * commands. unless I forced followed every input for a flake, my flake.lock would update every time I ran nix develop or nix build, I could run them directly after each other without changing anything within the repo and would get a different flake.lock each time, it would alternate between the "correct version" where some of the follows were respected, to the "incorrect version" where my follows would be ignored and the upstream flake's origin inputs would be followed. It was really really strange.

it could to the point where I couldn't even update inputs correctly, had 10 versions of nixpkgs in my flake.lock and the repl refused to run anything (citing change required in flake, but enable to change the lockfile), and the only thing I could do was delete flake.lock and try again