<clever>
matthewcroughan: https://dpaste.com/ARQQ55C79 if you use super on line 40, then you will be refering to the state of nixpkgs BEFORE this overlay was applied
<clever>
matthewcroughan: and you probably want self there, not super
<clever>
matthewcroughan: so you want python3Packages.mkdocs-macro-plugin
<clever>
matthewcroughan: your overlay is adding it to python3Packages
<clever>
matthewcroughan: the default name is "${pname}-${version}"
<clever>
or `nix build .#`
<clever>
nix build .#foo
<clever>
>> and then tell arch to remove nix
<clever>
but the arch one is earlier in $PATH
<clever>
you must have already had a copy of nix in `nix-env -q` before
<clever>
possibly
<clever>
> nixFlakes
<clever>
matthewcroughan: just do a plain nix-env -iA nixpkgs.nix, and let it stay in /nix/store
<clever>
matthewcroughan: even static, it will have references into /nix/store
<clever>
matthewcroughan: if nix is in /usr/bin/nix, then its being managed by arch, either tell arch to update it, or `nix-env -iA nixpkgs.nix` and then tell arch to remove nix
<clever>
supersandro2000: ah, ive been using a hand-written .service file, with a reference to ~/.nix-profile
<clever>
matthewcroughan: depends on what `which nix` returns
<clever>
yep
<clever>
tab-completion in nix repl is your friend
<clever>
matthewcroughan: spelling mistake
<clever>
propagatedBuildInputs
<clever>
it will be the 1st arg of whatever you gave to overrideAttrs
<clever>
it will instead be in oldAttrs
<clever>
it will never be on super or self
<clever>
propogatedBuildInputs is an attribute of a derivation, not a package set
<clever>
normally, that function is in a default.nix file
<clever>
that style is what lets nativeBuildInputs work, and also lets .override work
<clever>
thats defining a function, which is then passed to callPackage
<clever>
matthewcroughan: add future to the function on line 3
<clever>
matthewcroughan: can you pastebin the expr your using?
<clever>
if you set fetchSubmodules=true; it will instead run fetchgit, but you must invalidate the sha256
<clever>
it just downloads a .tar.gz of the commit
<clever>
fetchFromGitHub doesnt run git at any point
<clever>
same way you would override any other value, you must fully specify the new value
<clever>
matthewcroughan: src = fetchFromGitHub { all the args = ...; fetchSubmodules = true; };
2021-03-24
<clever>
jboy: your kernel must include kexec support
<clever>
the remote nix-daemon will enforce the same rules, and only somebody with root can violate them and polute the /nix/store your going to copy over
<clever>
pinpox: there are also things like hydra, which will farm the jobs out to remote hosts, you only need to trust that root hasnt been tampered with on the remote box
<clever>
pinpox: nix creates containers (using the same api as docker) to isolate all builds
<clever>
pinpox: the nix-daemon runs as root, and enforces that a given store path was made according to the directions in the .drv file, and hasnt been modified maliciously
<clever>
simpson: and now that sudo has setuid
<clever>
simpson: but you can copy over a malicious build of sudo, and then when you nixos-rebuild --upgrade, "oh, i already have that sudo, no need to DL"
<clever>
they can basically write any storepath that doesnt exist yet
<clever>
yeah
<clever>
which will upload to S3 for you
<clever>
there is also `nix copy --to s3://bucket /nix/store/foo`
<clever>
yeah
<clever>
yeah, but you could leave it in the /nix/store of the cache server
<clever>
nix-serve also saves you from having to figure out what to copy and when
<clever>
nix-serve avoids doubling your disk usage, by serving what is in /nix/store, rather then you having to make a copy of everything
<clever>
pinpox: this creates a directory full of .narinfo and .nar.xz files, which you can then just host with nginx
<clever>
apeyroux: it deals poorly with large files, and if the old and new string are of a different length, it will also break binary files
<clever>
and temporarily running `nix build /nix/store/foo.drv` on that final drv, can give you a better ui on the progress
<clever>
running the build with -Q can make it easier to see what is happening
<clever>
and you need to look at where the ones it wants to build are in that tree
<clever>
you can then run `nix-store -q --tree` on the final drv its going to build
<clever>
say*
<clever>
if you run that with --dry-run, what does its ay?
<clever>
but depending on the shape of the dep tree, there can be bottlenecks where only one drv is buildable at the moment
<clever>
the 30 is that field, so nix should be running 30 builds on the remote system
<clever>
s1341_: /etc/nix/machines has a field saying how many builds a machine can support
<clever>
its not until you do the .a or .b, does nix try to figure out what a= or b= evaluates ot
<clever>
so the `result` in fix, will return the `{a=...; b=...;}` part of the function, and the only special thing, is that any reference to `self` in the ..., now has a lazy reference to something
<clever>
so if you have something like: `f = self: { a=...; b=...; }` and then try to use `fix f` then nix will first look at fix, and do the code i explained before
<clever>
rydnr: nix is lazy, so it wont figure out what the arguments are, until something references it
<clever>
rydnr: if you write the function the right way, yeah
<clever>
rydnr: just a regular argument
<clever>
it doesnt need to know what self is, to figure out what `self: { a=...; b=...; }` is returning, as the root value
<clever>
and then it can keep computing things
<clever>
and now it knows that self is a set, with keys a&b
<clever>
then nix can figure out, that the top-level value is a set, with the keys a&b
<clever>
so if you do `f = self: { a=...; b=...; }`
<clever>
the trick, is that nix must be able to compute the top-level value of `f`, before its args
<clever>
rydnr: it only gets ran once, thru the magic of lazyness, that 1st run can depend on its own return value
<clever>
then i can mutate things before they go back in
<clever>
so it becomes more like `f (f2 result)`
<clever>
Ke: but, thru the magic of makeScope and overrideScope', i can insert a second function
<clever>
Ke: this function can be ran thru lib.fix, to map self to its own return value, and make everything work
<clever>
and that basically just creates local variables, private to the expr after the `in`
<clever>
any time you can have a value in nix, you can also have `let key=value; in value`
<clever>
then again, as the return value of the let block
<clever>
once to call f, and create result
<clever>
yeah, result gets used twice
<clever>
`f:` defines this as a function, that takes 1 argument, which will be named `f`
<clever>
`f result` then runs `f` with that lazy value
<clever>
`let result = ...` creates a lazy thunk, that will figure out the value of `result` at a later time
<clever>
rydnr: that simply runs `f`, and passes `f` its own return value as an argument
2021-03-21
<clever>
gurjeet: run `touch` on that path to make it again, then run `nix-store --delete` on the path, and next time, always use `nix-store --delete` to delete files