Building the nixpkgs manual currently triggers a bunch of deprecation
warnings, because every attribute in `lib` is evaluated to see if it's
an attrset to generate locations for.
Instead, share the lib subsets to include in the documentation
between `lib-function-docs` and `lib-function-locations` so they can
coordinate.
Also generate the list of sections instead of duplicating it in
`library.xml`.
Presenting an example with a patch (without even providing that patch!) is not ideal. Since `npm pack` now obeys `--ignore-scripts`, we can use that instead.
Avoids confusion: `vim-full`'s build-time features are configurable, but both
`vim` and `vim-full` are *customizable* (in the sense of user configuration).
If all the docs are auto-generated, it should be easier to convert
them to Commonmark.
Co-Authored-By: Valentin Gagarin <valentin.gagarin@tweag.io>
Co-Authored-By: Silvan Mosberger <contact@infinisil.com>
The nixpkgs manual contains references to both sri hash and explicit
sha256 attributes. This is at best confusing to new users. Since the
final destination is exclusive use of sri hashes, see nixos/rfcs#131,
might as well push new users in that direction gently.
Notable exceptions to sri hash support are builtins.fetchTarball,
cataclysm-dda, coq, dockerTools.pullimage, elixir.override, and
fetchCrate. None, other than builtins.fetchTarball, are fundamentally
incompatible, but all currently accept explicit sha256 attributes as
input. Because adding backwards compatibility is out of scope for this
change, they have been left intact, but migration to sri format has been
made for any using old hash formats.
All hashes have been manually tested to be accurate, and updates were
only made for missing upstream artefacts or bugs.
Promote the `maintainers = with maintainers; [ ]` syntax as that is most common
in nixpkgs, and remove the `nix-env` example which doesn't work like that anymore.
The `sparseCheckout` argument allows the user to specify directories or
patterns of files, which Git uses to filter files it should check-out.
Git expects a multi-line string on stdin ("newline-delimited list", see
`git-sparse-checkout(1)`), but within nixpkgs it is more consistent to
use a list of strings instead. The list elements are joined to a
multi-line string only before passing it to the builder script.
A deprecation warning is emitted if a (multi-line) string is passed to
`sparseCheckout`, but for the time being it is still accepted.
It gives a warning on the lazy-trees branch of Nix
(NixOS/nix#6530)
one of these was also giving me an error (the one in lib/trivial probably)
```
$ nix build
warning: applying 'toString' to path '/home/artturin/nixgits/my-nixpkgs/nixos/modules/installer/sd-card/sd
-image-aarch64.nix' and then accessing it is deprecated, at /home/artturin/nixgits/my-nixpkgs/lib/modules.
nix:349:99
warning: applying 'toString' to path '/home/artturin/nixgits/my-nixpkgs/.git' and then accessing it is dep
recated, at /home/artturin/nixgits/my-nixpkgs/lib/sources.nix:35:32
warning: applying 'toString' to path '/home/artturin/nixgits/my-nixpkgs/nixos/modules/system/etc/etc.nix'
and then accessing it is deprecated, at «stdin»:0
warning: applying 'toString' to path '/home/artturin/nixgits/my-nixpkgs/nixos/modules/system/etc/etc-activ
ation.nix' and then accessing it is deprecated, at «stdin»:0
warning: applying 'toString' to path '/home/artturin/nixgits/my-nixpkgs/nixos/modules/installer/sd-card/sd
-image-aarch64.nix' and then accessing it is deprecated, at «stdin»:0
error: cannot decode virtual path '/nix/store/virtual0000000000000000000000005-source'
(use '--show-trace' to show detailed location information)
```
A tricky thing about FreeBSD is that there is no stable ABI across
versions. That means that putting in the version as part of the config
string is paramount.
We have a parsed represenation that separates name versus version to
accomplish this. We include FreeBSD versions 12 and 13 to demonstrate
how it works.
https://github.com/NixOS/nixpkgs/pull/89885 ensures that fetches are
done securely (i.e. without `--insecure`) when the `hash` parameter is one of
the four special "fake" hashes. However the manual was not updated in that PR.
This commit updates the manual to account for the already-merged changes from
that PR.
Co-authored-by: Valentin Gagarin <valentin.gagarin@tweag.io>
Previously we had an assert that would complain when nugetDeps wasnt set,
which also didnt allow any passthru attributes (like fetch-deps) to be
build. That causes a cycle where you need nugetDeps to fetch the nuget
deps, but arent able to build the script to do so.
This was removed to simplify configuration. One could create a function that converts the plug format to vim native package format (only plugin system supported for neovim) and upstream it to nixpkgs if that's an issue
it is possible to maintain an out of tree list of neovim plugins with this method
Update doc/languages-frameworks/vim.section.md
Co-authored-by: Sandro <sandro.jaeckel@gmail.com>
This was a source of massive confusion for me when I first learned my way around nixpkgs' rust machinery. I seek to save others from that confusion.
* `buildRustPackage` should have been named `buildRustPackageUsingCargo`
* `buildRustCrate` should have been named `buildRustPackageUsingNix`
It is, unfortunately, too late to fix this. Let's do the next best thing and make the names `buildRustPackage` and `buildRustCrate` very prominent in the documentation, so readers see immediately that they need to learn the following jargon:
* `buildRustPackage` means "build this Rust crate by calling `cargo` in one (or two) monolithic derivations"
* `buildRustCrate` means "build this Rust crate by calling `rustc` in one derivation for each crate"
Fixes#186752. This adds buildVMMemorySize (defaults to 512 MiB) to
buildImage, which is passed to vm.runInLinuxVM. This is needed for
larger base images, which may otherwise cause container build failures
due to OOM in the VM.
Python package sets can be overridden by overriding an interpreter
and passing in `packageOverrides = self: super: {...};`. This is fine
in case you need a single interpreter, however, it does not help you
when you want to override all sets.
With this change it is possible to override all sets at once by
appending a list of "extensions" to `pythonPackagesExtensions`.
From reading the implementation you might wonder why a list is used, and
not
`lib.composeExtensions`? The reason is the latter requires knowledge of
the library function. This approach should be easier for most users
as it is similar to how we append to lists of e.g. inputs or patches
when overriding a derivation.
