!lymvtcwDJ7ZA9Npq:lix.systems

Lix Development

373 Members
(Technical) development of Lix, the package manager, a Nix implementation. Please be mindful of ongoing technical conversations in this channel.124 Servers

Load older messages


SenderMessageTime
23 Aug 2025
@emilazy:matrix.orgemilyin any case any new changes to a Lix release branch will never hit EOL Nixpkgs versions and I'm assuming that using Lix from the repo with EOL Nixpkgs versions is also not supported, so testing EOL versions in CI makes little sense for any branch23:14:16
@emilazy:matrix.orgemily aloisw: btw, one of the problems with keeping the old toml11 is that we need the new one for the CMake 4 bump 23:14:46
@emilazy:matrix.orgemilyso I would strongly prefer to just fix this23:14:57
@emilazy:matrix.orgemily(by need I mean: the old one will cause problems with CMake 4)23:15:41
@raitobezarius:matrix.orgraitobezarius
In reply to @emilazy:matrix.org
so most users will be using their actual Nixpkgs if they set the follow
i'm a non flake user :D
23:18:14
@emilazy:matrix.orgemilyactually it is not even about the flake input, I was wrong23:18:51
@emilazy:matrix.orgemilyit sets an overlay23:18:53
@raitobezarius:matrix.orgraitobezariusyeah23:18:57
@emilazy:matrix.orgemilyso it will be using the NixOS system's package set, regardless23:18:59
@raitobezarius:matrix.orgraitobezariushm yep23:19:10
24 Aug 2025
@lunaphied:lunaphied.meLunaphied Uhhhh 00:28:08
@lunaphied:lunaphied.meLunaphiedhm something about that seems off00:28:13
@lunaphied:lunaphied.meLunaphied
In reply to @raitobezarius:matrix.org
i'm a non flake user :D
I really need to get around to that change with supporting overrides in flake-compat
00:28:36
@raitobezarius:matrix.orgraitobezarius just give me https://git.afnix.fr/sprinkles/sprinkles 00:29:20
@lunaphied:lunaphied.meLunaphiedo.o what's this exactly?00:34:46
@raitobezarius:matrix.orgraitobezarius Charles attempts to bring a flake structure to the non-flake world 00:35:05
@raitobezarius:matrix.orgraitobezariusi personally like it, it's growing on me certainly00:35:16
@lunaphied:lunaphied.meLunaphiedhm, I guess we should look at that00:45:17
@emilazy:matrix.orgemily "source and input must be the only variables defined in the let binding." maintaining the vital flakes property of not being Nix I see :P 01:03:49
@charles:computer.surgeryCharles

that's mainly there to keep the structure consistent; if you want to define arbitrary stuff i usually have a let binding inside output like

{
  output = self:
    let
      inherit (self.input) nixpkgs;
      foo = 4;
    in
    {
      shell.default = nixpkgs.callPackage ./shell/default { inherit foo; };
    };
}

for example. other major difference from flakes is that e.g. source = import ./lon.nix; works and is a totally reasonable thing to do

01:23:08
@charles:computer.surgeryCharlesif you really don't want to follow a convention, then not following the convention is also an option, but then you don't get the benefits of following the convention01:24:40
@charles:computer.surgeryCharles *

that's mainly there to keep the structure consistent and make overrideability more consistently available; if you want to define arbitrary stuff i usually have a let binding inside output like

{
  output = self:
    let
      inherit (self.input) nixpkgs;
      foo = 4;
    in
    {
      shell.default = nixpkgs.callPackage ./shell/default { inherit foo; };
    };
}

for example. other major difference from flakes is that e.g. source = import ./lon.nix; works and is a totally reasonable thing to do

01:26:23
@charles:computer.surgeryCharles *

that's mainly there to keep the structure consistent and make overrideability more consistently available; if you want to define arbitrary stuff i usually have a let binding inside output like

# [stuff]
{
  # [stuff]

  output = self:
    let
      inherit (self.input) nixpkgs;
      foo = 4;
    in
    {
      shell.default = nixpkgs.callPackage ./shell/default { inherit foo; };
    };
}

for example. other major difference from flakes is that e.g. source = import ./lon.nix; works and is a totally reasonable thing to do

01:27:02
@emilazy:matrix.orgemily re "make overrideability more consistently available", is there non-Nix stuff parsing these files? (I'm struggling to understand what forbidding other let bindings achieves) 01:32:12
@charles:computer.surgeryCharlesnope01:32:28
@charles:computer.surgeryCharles when i say overrideability i mean the ability to do someSprinkle.override { source = { ... }; input = source: { ... }; } and have it affect everything in someSprinkle that should be affected 01:33:50
@charles:computer.surgeryCharles

there's not that much code for sprinkles.new but it is pretty dense, might help to try reading that to get an idea of what's going on?

  • https://git.afnix.fr/sprinkles/sprinkles/src/branch/v1/nix/lib/default.nix
  • https://git.afnix.fr/sprinkles/sprinkles/src/branch/v1/nix/lib/private.nix
01:35:14
@emilazy:matrix.orgemily ah, so the worry is capturing sprinkles in other definitions I suppose? 01:35:20
@charles:computer.surgeryCharlesnot entirely sure what you mean01:37:20
@charles:computer.surgeryCharlesi think i would maybe phrase it more like "the worry is being able to influence sources and inputs of other sprinkles"?01:38:02

Show newer messages


Back to Room ListRoom Version: 10