There are many different versions of the `cudatoolkit` and related
cuda packages, and it can be tricky to ensure they remain compatible.
- `cudaPackages` is now a package set with `cudatoolkit`, `cudnn`, `cutensor`, `nccl`, as well as `cudatoolkit` split into smaller packages ("redist");
- expressions should now use `cudaPackages` as parameter instead of the individual cuda packages;
- `makeScope` is now used, so it is possible to use `.overrideScope'` to set e.g. a different `cudnn` version;
- `release-cuda.nix` is introduced to easily evaluate cuda packages using hydra.
This commit describes the "->" notation for dependency types in
greater detail, and uses g++ to provide examples of all six cases
(although the host->target and target->target examples are a bit
artificial).
It also adds three more rows to the table for the "->*" dependency
types for non-compiler-like packages; these dependency types were
already present in the documentation but the "*" was not really
explained.
Lastly, this commit adds a hyperlink to the table from the place where
it is mentioned in the "specifying dependencies" chapter.
Allows restricting patches to a specific subdirectory, à la
`git diff --relative=subdir`.
This cannot be done (cleanly) currently because the `includes` logic
happens *after* `stripLen` is applied, so we can't match on `subdir/*`.
This change adds a `relative` argument that makes this possible by
filtering files before doing any processing, and setting `stripLen` and
`extraPrefix` accordingly.
The current wrapper only includes vim, gvim and the man pages
(optionally). This rewrite distinguishes two scenarios, which I expect
cover the majority of use cases:
- standalone mode, when `name != "vim"`, means the user already has a
vim in scope and only wants to add a customized version with a
different name. In this case we only include wrappers for `/bin/*vim`.
- non-standalone mode, when `name == "vim"`, means the user expects a
normal vim package that uses the specified configuration. In this case
we include everything in the original derivation, with wrappers for
all the executables that accept a vimrc.
types.optionSet has been deprecated for almost 10 years now
(0e333688ce)! A removal
was already attempted in 2019
(27982b408e), but it was promptly
reinstantiated since some third-party uses were discovered
(f531ce75e4).
It's finally time to remove it for good :)
Conflict in pkgs/development/libraries/libvirt/default.nix
required manual adjustments. The fetched patch is already in src.
I checked that libvirt builds.
The documentation for this diagram explains that the blue arrows are
automatic processes which happen every six hours. There is no
explanation about how the purple arrows happen or how often.
As a new contributor to nixpkgs, I incorrectly assumed that the purple
arrows were also automatic processes (they aren't), which left me sort
of confused about what the whole scheme was accomplishing.
Recently I went through the github history to see how often these
events happen, and realized that the purple arrows are (a) triggered
manually by a nixpkgs project member and (b) happen much, much, much
less frequently than every six hours.
Now everything makes a lot more sense. I suggest the wording change
in this commit, or something similar, to save future contributors the
same confusion that I experienced.
Few things going on in this commit:
Do not print "Building subPakage $pkg" message if actually going to skip the
package. This was confusing to me when I was trying to figure out how to set
excludedPackages and seeing the "Building subpackage $pkg" messages for
packages I wanted to skip. Turns out this messages was being printed before
checking if we actually wanted to build the package and not necessarily that my
excludedPackages was wrong.
Make go-packages look a little bit more like go-modules, by adding testdata to
the default list of excluded packages.
This commit also does some setup outside the buildGoDir function so that we
avoid checking `excludedPackages` for every package and cut down the number
of grep calls by half since we always want at least one grep for the default
excludedPackages, might as well just add to the patterns being checked.
Finally, adds documentation for usage of excludedPackages and subPackages. I
had to read the implementation to figure out how to correctly use these
function arguments since there was no documentation and different uses in the
code base. So this commit documents usage of the arguments.
The current doc is wildly out of touch with reality. A regex search shows
the following stats.
```
Style example Frequency Regex used
nix-2-5: 8 [a-zA-Z]-[0-9]+(-[0-9]+)+ =
nix-2_5: 17 [a-zA-Z]-[0-9]+(_[0-9]+)+ =
nix_2_5: 689 [a-zA-Z]_[0-9]+(_[0-9]+)+ =
nix_2-5: 1 [a-zA-Z]_[0-9]+(-[0-9]+)+ =
```
When I designed `mkShell`, I didn't have a good idea of what the output
should look like and so decided to make the build fail. In practice,
this causes quite a bit of confusion and complications because now the
shell cannot be part of a normal package set without failing the CI as
well.
This commit changes that build phase to record all the build inputs in a
file. That way it becomes possible to build it, makes sure that all the
build inputs get built as well, and also can be used as a GC root.
(by applying the same trick as #95536).
The documentation has also been improved to better describe what mkShell
does and how to use it.
CONFLICT (rename/add): Rename pkgs/development/python-modules/jsonwatch/default.nix->pkgs/tools/misc/jsonwatch/default.nix in nixpkgs/master. Added pkgs/tools/misc/jsonwatch/default.nix in HEAD
I found out how to use aspell with a custom dictionary and so ran that
on `rust.section.md`.
These changes are trivial consistency in spelling and nomenclature.
Naive concatenation of $LD_LIBRARY_PATH can result in an empty
colon-delimited segment; this tells glibc to load libraries from the
current directory, which is definitely wrong, and may be a security
vulnerability if the current directory is untrusted. (See #67234, for
example.) Fix this throughout the tree.
Followup to #76804. Fixes#144646.
Signed-off-by: Anders Kaseorg <andersk@mit.edu>
This stems from a discussion [here](https://discourse.nixos.org/t/what-rust-overlay-do-you-use-and-why-advice-appreciated/15412)
I removed an entire section because I feel like that duplicated
Mozilla's original instructions on how to consume the overlay.
The goal here is to simply the "getting started with Rust" in a nix or
NixOS environment.
I will try to do some follow up work to update the code snippets and
output. nightly is on `1.57.0-nightly` :)
