Change:
The main difference between `fetchurl` and `fetchzip` is in how they store the contents. `fetchurl` will store the unaltered contents of the URL within the Nix store. `fetchzip` on the other hand, will decompress the archive for you, making files and directories directly accessible in the future. `fetchzip` can only be used with archives. Despite the name, `fetchzip` is not limited to .zip files and can also be used with any tarball. <ins> ## `fetchpatch` {#fetchpatch} </ins> `fetchpatch` works very similarly to `fetchurl` with the same arguments expected. It expects patch files as a source and performs normalization on them before computing the checksum. For example, it will remove comments or other unstable parts that are sometimes added by version control systems and can change over time. <ins> - `relative`: Similar to using `git-diff`'s `--relative` flag, only keep changes inside the specified directory, making paths relative to it. - `stripLen`: Remove the first `stripLen` components of pathnames in the patch. - `extraPrefix`: Prefix pathnames by this string. - `excludes`: Exclude files matching these patterns (applies after the above arguments). - `includes`: Include only files matching these patterns (applies after the above arguments). - `revert`: Revert the patch. Note that because the checksum is computed after applying these effects, using or modifying these arguments will have no effect unless the `sha256` argument is changed as well. </ins> Most other fetchers return a directory rather than a single file. ## `fetchsvn` {#fetchsvn}

Discussion:
has only basic documentation for its so far. For example, the and / options aren't documented. That makes it very error-prone to use. For example, it would be useful to know that runs before . That means that if you have paths like and you try to keep only the parts using then this won't work, because will already strip off and , so your won't work and there is no you could possibly write to achieve the goal. That would be nice to know ahead of time.
In addition to documenting the options, some guidelines on when to use and when to add a patch to the nixpkgs repo would be helpful. This question comes up frequently in PRs.
Thank you for your contributions. This has been automatically marked as stale because it has had no activity for 180 days. If this is still important to you, we ask that you leave a comment below. Your comment can be as simple as "still important to me". This lets people see that at least one person still cares about this. Someone will have to do this at most twice a year if there is no other activity. Here are suggestions that might help resolve this more quickly: for maintainers and people that previously touched the related code and @ mention them in a comment. on the . on the on .
I still think this should be documented.
I marked this as stale due to inactivity. &rarr;
still
would you be up to starting a PR on what you figured out so far? Happy to review what you come up with, and add notes :-)
I marked this as stale due to inactivity. &rarr;
Here's what we have currently documented, in : It seems that the options are documented now, only the detail that if is used, it is handled before ? I didn't quiet understand what you tried to explain
Documented in .
I think the confusing part here is that the arguments for are documented in , not . I'll send a PR moving it to the latter location, and a hyperlink to the former.
PR up at , PTAL.