This has several advantages:
1. It takes up less space on disk in-between builds in the nix store.
2. It uses less space in the binary cache for vendor derivation packages.
3. It uses less network traffic downloading from the binary cache.
4. It plays nicely with hashed mirrors like tarballs.nixos.org, which only
substitute --flat hashes on single files (not recursive directory hashes).
5. It's consistent with how simple `fetchurl` src derivations work.
6. It provides a stronger abstraction between input src-package and output
package, e.g., it's harder to accidentally depend on the src derivation at
runtime by referencing something like `${src}/etc/index.html`. Likewise, in
the store it's harder to get confused with something that is just there as a
build-time dependency vs. a runtime dependency, since the build-time
src dependencies are tarred up.
Disadvantages are:
1. It takes slightly longer to untar at the start of a build.
As currently implemented, this attaches the compacted vendor.tar.gz feature as a
rider on `verifyCargoDeps`, since both of them are relatively newly implemented
behavior that change the `cargoSha256`.
If this PR is accepted, I will push forward the remaining rust packages with a
series of treewide PRs to update the `cargoSha256`s.
When updating the section to python 3 some places still
referred to pythonPackages and were overlooked.
Decided to switch it to be more similar to the first
example binding pythonPackages and clarified comments a
bit based on confusion I observed on IRC.
Related to https://github.com/NixOS/nixpkgs/pull/77569
Updating section about imperative use of ad-hoc virtual-environments for
use of pythons built-in `venv` module via venvShellHook. Also trying to
make it a bit friendlier to beginners by adding a bit more explanation
to the code snippet and some remarks old-school virtualenv.
Adjusting for venvShellHook and adding manual example
Adding pip install and replacing python2 example with python3
When modSha256 is null, disable the nix sandbox instead of using a
fixed-output derivation. This requires the nix-daemon to have
`sandbox = relaxed` set in their config to work properly.
Because the output is (hopefully) deterministic based on the inputs,
this should give a reproducible output. This is useful for development
outside of nixpkgs where re-generating the modSha256 on each mod.sum
changes is cumbersome.
Don't use this in nixpkgs! This is why null is not the default value.
We shouldn’t force the user to have a C compiler in scope, just
because the derivation is forced to build locally. That can’t be
counted as “lightweight” anymore.
Co-Authored-By: Silvan Mosberger<contact@infinisil.com>
This has the same motivation as fetchFromGitHub/fetchFromGitLab --
it's cheaper to download a tarball of a single revision than it is to
download a whole history.
I could have gone with domain/group/repo, like fetchFromGitLab, but it
would have made implementation more difficult, and this syntax means
it's a drop-in replacement for fetchgit, so I decided it wasn't worth
it.
