!UUqahLbShAYkkrXmKs:matrix.org

DevOS

37 Members
Seeking help and geeking out together on https://github.com/divnix/devos & https://github.com/divnix/digga10 Servers

Load older messages

SenderMessageTime
4 Dec 2021
@blaggacao:matrix.orgDavid Arnold (blaggacao)^ would have been my comment, if I could.20:28:35
@blaggacao:matrix.orgDavid Arnold (blaggacao)* ^^ would have been my comment, if I could.20:28:42
@blaggacao:matrix.orgDavid Arnold (blaggacao) Gytis Ivaskevicius: maybe you remembered when I tried some in fup once. These had been quite bit cleaner had there been right associativity. 20:29:32
@blaggacao:matrix.orgDavid Arnold (blaggacao)* Gytis Ivaskevicius: maybe you remember when I tried some in FUp once. These had been quite bit cleaner had there been right associativity.20:29:59
@blaggacao:matrix.orgDavid Arnold (blaggacao)* Gytis Ivaskevicius: maybe you remember when I tried some in FUP once. These had been quite bit cleaner had there been right associativity.20:30:04
7 Dec 2021
@kraftnix:matrix.org@kraftnix:matrix.org

hey all, is anyone having issues with the latest digga where the deploy flake input is no longer following digga's nixpkgs.follows when using deploy.follows = "digga/deploy in a devos-like setup?

not sure if I explained that well, basically since updating from a55450a16d362b6e1c50bb4025aaa604b385d3ba to latest on main, I suddenly have a duplicated nixpkgs which only deploy uses.

19:23:58
@kraftnix:matrix.org@kraftnix:matrix.org I also suddenly have three different flake-utils in my lockfile as well, i tend to make all my flake inputs use the same inputs as each other to reduce the size of my closures (particularly for nixpkgs, but I like to do it for all), and this latest updates has introduced a lot of duplicates where I haven't had any for months 19:27:34
@kraftnix:matrix.org@kraftnix:matrix.org

so the only way I managed to workaround and get my devos to behave like it used to (force all inputs to be followed correctly) was to add this horrible best in my inputs:

      deploy.url = "github:serokell/deploy-rs";
      deploy.inputs.nixpkgs.follows = "latest";
      deploy.inputs.utils.follows = "flake-utils-plus/flake-utils";
      digga.inputs.deploy.follows = "deploy";
      digga.inputs.flake-utils.follows = "flake-utils";
      digga.inputs.flake-utils-plus.follows = "flake-utils-plus";
      digga.inputs.beautysh.follows = "beautysh";

      flake-utils.url = "github:numtide/flake-utils";
      flake-utils-plus.url = "github:divnix/flake-utils-plus";
      flake-utils-plus.inputs.flake-utils.follows = "flake-utils";

      bud.inputs.beautysh.follows = "beautysh";
      beautysh.url = "github:lovesegfault/beautysh";
      beautysh.inputs.nixpkgs.follows = "nixos";
      beautysh.inputs.flake-utils.follows = "flake-utils-plus/flake-utils";
      beautysh.inputs.poetry2nix.follows = "poetry2nix";
      poetry2nix.url = "github:nix-community/poetry2nix";
      poetry2nix.inputs.flake-utils.follows = "flake-utils-plus/flake-utils";
      poetry2nix.inputs.nixpkgs.follows = "nixos";

as well as changing all other follows that use flake-utils from digga/flake-utils-plus/flake-utils to flake-utils-plus/flake-utils, it's pretty nasty and I'd rather not have to define these dependencies in my flake inputs when I don't really care about them that much (such as beautysh, poetry2nix) and i'd rather keep following digga's fu and fup without having to deal with the inputs myself, does anyone know why this change might have happened?

19:49:59
@kraftnix:matrix.org@kraftnix:matrix.org *

so the only way I managed to workaround and get my devos to behave like it used to (force all inputs to be followed correctly) was to add this horrible beast in my inputs:

      deploy.url = "github:serokell/deploy-rs";
      deploy.inputs.nixpkgs.follows = "latest";
      deploy.inputs.utils.follows = "flake-utils-plus/flake-utils";
      digga.inputs.deploy.follows = "deploy";
      digga.inputs.flake-utils.follows = "flake-utils";
      digga.inputs.flake-utils-plus.follows = "flake-utils-plus";
      digga.inputs.beautysh.follows = "beautysh";

      flake-utils.url = "github:numtide/flake-utils";
      flake-utils-plus.url = "github:divnix/flake-utils-plus";
      flake-utils-plus.inputs.flake-utils.follows = "flake-utils";

      bud.inputs.beautysh.follows = "beautysh";
      beautysh.url = "github:lovesegfault/beautysh";
      beautysh.inputs.nixpkgs.follows = "nixos";
      beautysh.inputs.flake-utils.follows = "flake-utils-plus/flake-utils";
      beautysh.inputs.poetry2nix.follows = "poetry2nix";
      poetry2nix.url = "github:nix-community/poetry2nix";
      poetry2nix.inputs.flake-utils.follows = "flake-utils-plus/flake-utils";
      poetry2nix.inputs.nixpkgs.follows = "nixos";

as well as changing all other follows that use flake-utils from digga/flake-utils-plus/flake-utils to flake-utils-plus/flake-utils, it's pretty nasty and I'd rather not have to define these dependencies in my flake inputs when I don't really care about them that much (such as beautysh, poetry2nix) and i'd rather keep following digga's fu and fup without having to deal with the inputs myself, does anyone know why this change might have happened?

19:50:23
9 Dec 2021
@cw:kernelpanic.cafe@cw:kernelpanic.cafe

https://github.com/divnix/devos/blob/main/flake.nix has a bit that refers to core at line 126: base = [ core users.nixos users.root ];

what is that core and where is it defined?

02:19:40
@cw:kernelpanic.cafe@cw:kernelpanic.cafeAnswering: https://github.com/divnix/devos/blob/287cb82d1ccd74693ae844869baa34228f143c21/profiles/core/default.nix 02:21:01
@cw:kernelpanic.cafe@cw:kernelpanic.cafe

I try to enter nix-shell in my devos folder and get error: attribute 'cw' missing, at /nix/store/... which is the middle line here:

            suites = with profiles; rec {
              base = [ core users.cw users.root ];
            };

my user is defined in users/cw/default.nix so it should be raked in. any ideas?

06:21:51
@danielphan.2003:matrix.org@danielphan.2003:matrix.org Have you staged users/cw/default.nix in git? 06:45:36
@cw:kernelpanic.cafe@cw:kernelpanic.cafeno!07:22:42
@cw:kernelpanic.cafe@cw:kernelpanic.cafestaging didn't help07:25:58
@cw:kernelpanic.cafe@cw:kernelpanic.cafeOddly though, the cw user change wasn't staged07:26:24
@cw:kernelpanic.cafe@cw:kernelpanic.cafe * Oddly though, the cw user change wasn't staged either07:26:41
@cw:kernelpanic.cafe@cw:kernelpanic.cafe
In reply to @cw:kernelpanic.cafe
no!
Not intended to be bitchy, lol 		08:20:42
@blaggacao:matrix.orgDavid Arnold (blaggacao)
In reply to @kraftnix:matrix.org

hey all, is anyone having issues with the latest digga where the deploy flake input is no longer following digga's nixpkgs.follows when using deploy.follows = "digga/deploy in a devos-like setup?

not sure if I explained that well, basically since updating from a55450a16d362b6e1c50bb4025aaa604b385d3ba to latest on main, I suddenly have a duplicated nixpkgs which only deploy uses.

At work I learned that the follows inputs are not completely gone and that the only really effective way 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.
14:27:48
@blaggacao:matrix.orgDavid Arnold (blaggacao) I also may add, that even if it is a "horrible beast" indeed, it's also more transparent and locally reasonable. The latter is a huge win in complexity reduction. 14:29:18
@blaggacao:matrix.orgDavid Arnold (blaggacao)* I also may add, that even if it is a "horrible beast" indeed, it's also more transparent and locally reasonable. The latter is a huge win in complexity containment.14:29:46
@blaggacao:matrix.orgDavid Arnold (blaggacao) 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. 14:37:25
@blaggacao:matrix.orgDavid Arnold (blaggacao) Especially for the latter, the pain of hidden side effects due to incompatibilities between version is also a lot bigger than the gain in closure size reduction or cleanup of the lock file: for example, at one point flake-utils introduced aarch64-darwin and some packages wheren't ready & that broke downstream CIs. 14:39:25
@blaggacao:matrix.orgDavid Arnold (blaggacao)* Especially for the latter, the pain of hidden side effects due to incompatibilities between version is also a lot bigger than the gain in closure size reduction or cleanup of the lock file: for example, at one point flake-utils introduced `aarch64-darwin` as a default system and some packages wheren't ready & that broke downstream CIs.14:40:04
@blaggacao:matrix.orgDavid Arnold (blaggacao)* Especially for the latter, the pain of hidden side effects due to incompatibilities between version is also a lot bigger than the gain in closure size reduction or cleanup of the lock file: for example, at one point flake-utils introduced `aarch64-darwin` as a default system and some packages wheren't ready & that broke downstream CIs, because flake checks started failing.14:40:35
@blaggacao:matrix.orgDavid Arnold (blaggacao)* Especially for the latter, the pain of hidden side effects due to incompatibilities between version is also a lot bigger than the gain in closure size reduction or cleanup of the lock file: for example, at one point flake-utils introduced `aarch64-darwin` as a default system and some packages wheren't ready & that broke downstream CIs, because flake checks started failing, iirc.14:40:43
@blaggacao:matrix.orgDavid Arnold (blaggacao)* At work I learned that the issues with follows inputs are not completely gone and that the only _really_ effective way 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.14:41:02
@blaggacao:matrix.orgDavid Arnold (blaggacao)* At work I learned that the issues with follows inputs are not completely gone and that the only _really_ effective way 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.14:41:12
@blaggacao:matrix.orgDavid Arnold (blaggacao)* 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.14:42:05
@blaggacao:matrix.orgDavid Arnold (blaggacao) 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. 14:43:34

Show newer messages

Back to Room ListRoom Version: 6