without stable ids on headings we cannot generate stable links to these
headings. nrd complains about this, but the current docbook workflow
does not.
a few generated ids remain, mostly in examples and footnotes. most of
the examples are generated by nixdoc (which has since gained MD export
functions, and the MD export does generate IDs).
This allows packages that require several dotnet versions to build (like
BeatSaberModManager) to properly depend on the dotnet-sdk specific deps.
This in turns avoids having to regenerate the deps of those packages
after each dotnet-sdk update.
This also changes nuget-to-nix to accept a file with a list of
exclusions instead of a folder.
The headings for the Rust section are structured incorrectly in two ways:
1. The section "Compiling non-Rust packages that include Rust code" is totally specific to `buildRustPackage`. It should be a child of the "Compiling Rust applications with Cargo" section.
1. The section "Setting up `nix-shell`" is totally specific to `buildRustCrate`. It should be a child of the "Compiling Rust crates using Nix instead of Cargo" section.
- Rust
- Compiling Rust applications with Cargo
- ...
- Compiling non-Rust packages that include Rust code
- ...
- Compiling Rust crates using Nix instead of Cargo
- ...
- Setting Up `nix-shell`
- ...
- Rust
- Compiling Rust applications with Cargo
- ...
- Compiling non-Rust packages that include Rust code
- ...
- Compiling Rust crates using Nix instead of Cargo
- ...
- Setting Up `nix-shell`
- ...
The previous approach of trying to make both the `override` mechanism from
`mkDerivation` and the `overrideScope'` mechanism from `newScope` work together
resulted in hard to understand code, and there was a bug where once overridden
packages would lose the changes on next override with `packageOverrides`.
It's not ideal still, because Lisps created by `mkDerivation` will lose their
`pkgs` after using `override`.
The previous approach of manually repeating a complex pattern inside Common Lisp
implementation package declarations was fragile and hard to change. After
reading python and lua modules code in Nixpkgs, I was able to come up with
something better.
The function `wrapLisp` doesn't need to be inside package declarations so all
the code for wrapping Lisps can be in `all-packages.nix`.
This works by wrapping the `override` function created from `mkDerivation` to
accept a new argument `packageOverrides`.
One problem with this is that `override.__functionArgs` disappears. But one can
look at the source code of a package to discover what can be overridden.
It won't be enough to fix cross in all cases, but it is in at least
one: pywayland. I've only made the change in cases I'm confident it's
correct, as it would be wrong to change this when python.interpreter
is used in wrappers, and possibly when it's used for running tests.
According to the Unicode Standard, you should use U+2019 RIGHT SINGLE
QUOTATION MARK for apostrophes [1]. Before this change, some of the text
in this repo would use U+2018 LEFT SINGLE QUOTATION MARKs instead.
[1]: https://www.unicode.org/versions/Unicode15.0.0/ch06.pdf#G12411
See docs.
Follow-up work:
- Existing packages should be converted
- `defaultPkgConfigPackages` should assert on `meta.pkgConfigModules`
and let `tests.pkg-config` alone test the build results.
CC @sternenseemann
Co-authored-by: Robert Hensing <roberth@users.noreply.github.com>
The name should end in Array per the current conventions.
This change also contains some minor formatting fixes, as the heading
levels were inconsistent.
- Replace cmdline-tools with tools because tools is obsolete now.
- Depend emulator package to systemImages
androidenv: fix issues on the PR
androidenv: reformat
androidenv: support excluding of `tools` package
androidenv: provide `tools`, and `build-tools`, dependencies
androidenv: replace includeTools with toolsVersion
androidenv: fix a typo
androidenv: add tests to check licenses and installed packages
androidenv: check if tests are running! this commit should fail!
androidenv: fix problems in the review https://github.com/NixOS/nixpkgs/pull/208793
androidenv: add test-suite to handle more tests around
androidenv: fix the test after couldn't running them with ofborg
Update pkgs/development/mobile/androidenv/build-tools.nix
Co-authored-by: Sandro <sandro.jaeckel@gmail.com>
androidenv: Resolving https://github.com/NixOS/nixpkgs/pull/208793#discussion_r1065851539
Update pkgs/development/mobile/androidenv/cmdline-tools.nix
Co-authored-by: Sandro <sandro.jaeckel@gmail.com>
Update pkgs/development/mobile/androidenv/tools.nix
Co-authored-by: Sandro <sandro.jaeckel@gmail.com>
androidenv: fix a typo
These are some suggested changes to the new documentation of Haskell in
the Nixpkgs manual. They cover sections until, but excluding, the
section "Available package versions". I am not an English native
speaker, so please correct me and savage these changes!
Also, please let me know if the suggestions are welcome, then I will
continue with the next chapter.
This restarts a Haskell section in the nixpkgs manual. The content
presented here has been written from scratch, although some parts of it
take inspiration from the existing haskell4nix documentation.
It is by no means complete, the idea is mostly to get the ball rolling
in some way. Upcoming tasks are hinted at in the comments in the
documentation file.
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).
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.
