<Shados>
teto: Is update-luarocks-package meant to actually work at the moment? I'm trying to run it on an unmodified luarocks-packages.csv in nixos-unstable, and it's throwing an error because it doesn't expect the "maintainers" column in the csv
<teto>
Shados: ah gosh I might have forgotten to bump the nixpkgs version sorry
<teto>
the master version takes adds the maintainer field to the derivation but I've got an issue with the shell expansion delaying the update
<Shados>
What do you mean by "shell expansion delaying the update"?
<teto>
Shados: I would like to fix an issue with the script before pushing an update. Do you need a quickfix ? you could change the luarocks-nix src in an overlay or patch locally the `read ` line of update-luarocks-package
drakonis_ has joined #nixos-dev
<Shados>
I'll probably do that, but I was interested in what the problem is
drakonis has quit [Ping timeout: 248 seconds]
MichaelRaskin has quit [Ping timeout: 258 seconds]
teto1 has joined #nixos-dev
<Shados>
teto: Ran into another problem, caused by update-luarocks-packages being tightly dependent on the version of luarocks-nix used, while just picking whatever version shows up first in NIX_PATH. You could maybe change the nix-shell shebang to use the luarocks-nix from the same nixpkgs checkout as the script is being run from?
<teto>
Shados: it should work at all times, pinning luarocks-nix won't work if I pin to a wrong version. a test would be more useful. Anyway the tool/integration in nixpkgs is fairly recent, hence the problems. Hopefully it shouldn't change much now (at least regarding the csv format)
teto has quit [Quit: WeeChat 2.4]
orivej has joined #nixos-dev
avn_ has quit [Remote host closed the connection]
teto1 is now known as teto
FRidh has joined #nixos-dev
drakonis has joined #nixos-dev
drakonis_ has quit [Ping timeout: 248 seconds]
dhess has quit [Ping timeout: 248 seconds]
init_6 has joined #nixos-dev
<Shados>
teto: My suggestion is not to pin it, but rather that in the nix-shell shebang for update-luarocks-packages, it could be better to e.g. point to an update-luarocks-packages.nix file that imports the nixpkgs it is contained (via a relative path) and provides luarocks-nix from that nixpkgs.
v0|d has quit [Ping timeout: 272 seconds]
<teto>
Shados: the thing is the csv file is supposed to always work with the luarock-nix of the same nixpkgs. I just happened to forget to bump it once. Adding an extra indirection won't change anything if I make another mistake. I might have been less careful also because I planned another update this week and I seem to be the only one using it xD
drakonis1 has joined #nixos-dev
phreedom has quit [Remote host closed the connection]
phreedom has joined #nixos-dev
init_6 has quit []
Synthetica has joined #nixos-dev
jtojnar has quit [Remote host closed the connection]
v0|d has joined #nixos-dev
<Shados>
teto: I think you're missing my point -- this isn't about the csv file. This is about the update script. The update script is tightly coupled to the version of luarocks-nix, but the way its nix-shell shebang is written currently means that it uses whatever version comes up first in $NIX_PATH. Which isn't necessarily the right one.
<teto>
Shados: I see . Doesnt `nix-shell -p` prepend it to PATH so that it gets first though ?
<Shados>
update-luarocks-packages is in.
<Shados>
teto: `#!nix-shell -p nix-prefetch-scripts luarocks-nix -i bash` adds `nix-prefetch-scripts luarocks-nix` to the environment that the script is run in, yes. But where does it select those attributes from? It grabs the first matching ones from the $NIX_PATH, which typically means whatever nixpkgs channel the person running it happens to have installed. So the version of luarocks-nix being run is taken from there, instead of from the nixpkgs checkout that
<teto>
sry your point was about NIX_PATH.
<Shados>
nix-shell in a shebang line doesn't work relative to the caller's cwd, so it doesn't use default.nix from the nixpkgs checkout your shell happens to be sitting in
<gchristensen>
one reason I think this makes sense is if it can't resolve it probably can't resolve anything else, so it won't go off building the world unless it already has the source to the world
<niksnut>
gchristensen: looks good
<gchristensen>
is this the right way to do it?
Jackneill has quit [Remote host closed the connection]
<niksnut>
it only matters if you have a proxy configured I guess?
<gchristensen>
no, if you try to do a nix-build and your network is down, it'll consider it a NotFound
<niksnut>
why?
<gchristensen>
right now it'll just try and try and try and then fail, this feels closer to the most right thing
<niksnut>
ah sorry, I only saw the RESOLVE_PROXY error
<niksnut>
however we've learned that there is no such thing as a permanent error
<gchristensen>
the use case I want to support better is you've run nix-build before, you have all your dependencies locally fetched, you're going to do a nix-build on a plane, but it gets hung up on trying to see if it is already built and in the cache
<{^_^}>
#61139 (by adisbladis, 4 weeks ago, merged): python-packages: Set pythonPackages attr in pythonPackages scope
<clever>
gchristensen: the mac failed to boot today, restarting qemu caused it to boot normally, https://i.imgur.com/A6KbKk1.png
<clever>
gchristensen: i vnc'd back in, and saw dsmos being mentioned, but in a different font, which changes further along in the boot process, so it was nowhere near dsmos i believe