<infinisil>
Hm in #69660 the author adds their own package with probably nobody but themselves using it. It also includes a NixOS module, more of which will slow down rebuilds for everybody (#57477)
<infinisil>
Maybe we could have some kind of voting system, that all PRs that add a new package need at least one "I want to use this too"-style comment or a +1 to be eligible for merging
<gchristensen>
guidelines would be better
<infinisil>
guidelines are hard to judge/enforce
drakonis has joined #nixos-dev
<infinisil>
I think knowing that at least 2 people are interested in a package would be a decent and simple indicator
<infinisil>
for it at least having somewhat of a userbase
<samueldr>
guidelines could somewhat codify that through asking for "notable" or "popular" packages, where popular is more about the concept, even a small number could be "popular" for nixpkgs
<infinisil>
I worry that there could easily be disagreement, the author of course would think it's popular enough but the potential merger doesn't feel the same
<simpson>
infinisil: In English we have the phrase "chicken and egg" for this sort of situation. It's unreasonable to expect demand to materialize without supply; it's already miraculous enough that people write Nix expressions given the current non-guarantee of merge.
<infinisil>
Hm yes that's a good point
<infinisil>
People might try `nix-env -iA nixos.florp` and give up immediately if it's not found
<danderson>
fwiw, I quite like the Arch linux model for this. There's core Arch, which has a build system and promises re: breaking things; and AUR, where anyone can upload stuff, with a lightweight way to claim abandoned packages, but fewer promises that it'll work
<infinisil>
I've heard this is a pretty big security problem because so many things aren't available in core
<simpson>
danderson: The dynamics are different there because of who builds the binaries.
<samueldr>
though tbf, core and extra could realistically be merged and things would keep working the same
<samueldr>
though the layering of community between AUR and core/extra is notable
<danderson>
simpson: presumably nixos could similarly decline to build cached versions of an aur-alike?
<danderson>
sorry, nix, not nixos. You know what I mean.
<simpson>
danderson: Sure, and that's already what we've got at the edges of nixpkgs, let alone NUR.
marek has quit [Changing host]
marek has joined #nixos-dev
<hyperfekt>
Ugh, I'm trying to decide whether I want to parse nix-instantiate --eval output, use hnix, or extend nix-the-tool and I'm not sure how to. I guess it depends on how easy hooking into the nix eval code is and how closely hnix follows upstream Nix, and what the chances of getting the tool I'm building accepted into the Nix codebase are.
<gchristensen>
what do you want out of the output?
<hyperfekt>
gchristensen: An attribute set of .drvs from an attribute set of derivations. The plan is to merge the results of calling each into an existing attribute set and print that.
<hyperfekt>
The whole thing is to become a dependency management tool, which can create new / updated entries in a 'lockfile' (which is in Nix for easy consumption) from a set of update instructions.
drakonis has quit [Ping timeout: 240 seconds]
ris has joined #nixos-dev
Jackneill has quit [Remote host closed the connection]
<__monty__>
hyperfekt: Sounds a bit flakey.
<__monty__>
: )
<hyperfekt>
__monty__: The general concept? As long as you want to avoid one file per dependency it'll be hard to get around doing some parsing...
<__monty__>
hyperfekt: It was a joking reference to the flakes RFC and its lockfile.
<hyperfekt>
clever: Yeah, using .drvPath on all the derivations and parsing the resulting attrset with rnix was my plan for the nix-instantiate variant.
<clever>
hyperfekt: nix-instantiate can output json too
<clever>
hyperfekt: either with builtins.toJSON or --json
<clever>
hyperfekt: there is also --xml, which supports more types then --json
<hyperfekt>
__monty__: Yeah, that's true, they're not dissimilar. Flake lockfiles only work for other flakes though, instead of arbitrary dependencies, otherwise I wouldn't do this.
cjpbirkbeck has joined #nixos-dev
pie_ has joined #nixos-dev
ixxie has quit [Ping timeout: 240 seconds]
psyanticy has quit [Quit: Connection closed for inactivity]
<samueldr>
hm, we get X stuff leaking into the minimal image again I think
* samueldr
digs
justanotheruser has quit [Ping timeout: 240 seconds]
justanotheruser has joined #nixos-dev
pie_ has quit [Ping timeout: 245 seconds]
<samueldr>
can't exactly pinpoint when, and bisecting may take a while, though it's something about rngd-tools, requiring opensc, which has some X11 deps
<samueldr>
right, ignore the "X stuff leaking" bit, it's not new; though it was causing issues with cross-compilation, traced it to https://github.com/NixOS/nixpkgs/pull/68072 that upgrade once reverted fixes cross-compilation; looking into it now
<samueldr>
luckily upstream fixed the issue in the next commit
drakonis has joined #nixos-dev
drakonis has quit [Read error: Connection reset by peer]
<infinisil>
globin: Regarding making mkRemovedOptionModule fail evaluation, there's a problem with that, namely that if you get an error, you have no idea where it's coming from!
<infinisil>
Just now I'm updating a bunch of stuff, and I get `trace: Obsolete option `system.nixosLabel' is used. It was renamed to `system.nixos.label'.` and I have no idea where nixosLabel is used
<infinisil>
It's certainly not in my config
<infinisil>
(this is for mkRenamedOptionModule now, but it's the same problem for mkRemovedOptionModule)
<infinisil>
I guess this is a disadvantage to IFD, because if I'd have all the nix code checked out in my config, I could just ripgrep for nixosLabel to find it, but I can't because I use IFD
<infinisil>
Oh actually, that was just me being a bit stupid, I evaluated `nix-instantiate '<nixpkgs/nixos>' -A config.system`
<infinisil>
But it should be `nix-instantiate '<nixpkgs/nixos>' -A system`
<infinisil>
Or `nix-instantiate '<nixpkgs/nixos>' -A config.system.build.toplevel`
<infinisil>
Duh
cjpbirkbeck has quit [Quit: Quitting now.]
__monty__ has quit [Quit: leaving]
<infinisil>
But still, in Nix we have this problem that we have no idea where warnings come from
<infinisil>
This can almost be added to the list of fundamental existing problems with Nix