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.
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"
