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

Another unrelated question.
I do not understand where my package come from. I thought they be coming from nixpkgs/nixos-unstable because I have this in my flake.nix:

  inputs = {
    nixos.url = "github:nixos/nixpkgs/nixos-unstable";

But after I nix flake update and rebuild, I seem to have packages coming from a 22-days old commit of the nixos-unstable branch 🤔

In reply to @Sweenu:matrix.org
Hey! I'm trying to use nix-on-droid with digga. Is it possible to have your phone be like any other host, using profiles and suites with the exception that is uses nix-on-droid? I don't quite understand how I would do that in the flake.nix...

In reply to @Sweenu:matrix.org

Another unrelated question.
I do not understand where my package come from. I thought they be coming from nixpkgs/nixos-unstable because I have this in my flake.nix:

  inputs = {
    nixos.url = "github:nixos/nixpkgs/nixos-unstable";

But after I nix flake update and rebuild, I seem to have packages coming from a 22-days old commit of the nixos-unstable branch 🤔

Thanks for your answers! I'm checking with poetry. On my machine it is at version 1.10 but as you can see here https://github.com/NixOS/nixpkgs/blame/master/pkgs/development/python-modules/poetry/default.nix#L27 it's been updated to 1.12 17 days ago. I checked the flake.lock and the nixos section is at the latest commit (~12 hours ago).

Here's my full flake.nix: https://gist.github.com/sweenu/a432ff3feb9b55375f328c49a61860db

kraftnix: Thanks for your answers! I'm checking with poetry. On my machine it is at version 1.10 but as you can see here https://github.com/NixOS/nixpkgs/blame/master/pkgs/development/python-modules/poetry/default.nix#L27 it's been updated to 1.12 17 days ago. I checked the flake.lock and the nixos section is at the latest commit (~12 hours ago).

Here's my full flake.nix: https://gist.github.com/sweenu/a432ff3feb9b55375f328c49a61860db

In reply to @kraftnix:matrix.org
so I can't see anything particularly wrong with your flake, but since I don't have the rest of the repo I can only make assumptions as to how it's set up and how you are trying to use poetry, especially since I can't see the flake.lock file in the gist. do you have many nixpkg inputs in your lockfile? is the issue isolated to poetry or across all packages? otherwise you might be hitting the follows + direnv bug that has been mentioned recently above (that has also affected me) as you don't have any anti-corruption layer (see devos' flake.nix)