* buildGoModule: don't inherit postBuild hook when building go-modules
This is a slight revert of 5ce647b8bf
(#212800).
Inheriting these hooks in the `.go-modules` derivation can be confusing:
One doesn't expect them to run when generating the fixed output modules
derivation, but only on the main derivation. A `postBuild` hook that
adds some files to $out will cause a very hard to debug issue[1].
This commit adds support for a dedicated `modPostBuild` hook that will
be used only by the derivation building `.go-modules`. Additionally,
`go.section.md` now explains these attributes behavior better.
[1]:
https://discourse.nixos.org/t/cant-update-a-go-package-getting-go-inconsistent-vendoring/27063/6
Co-authored-by: Sandro <sandro.jaeckel@gmail.com>
* update.py: introduce subparsers for plugin updaters
This is preliminary work to help create more powerful plugin updaters.
Namely I would like to be able to "just add" plugins without refreshing
the older ones (helpful when github temporarily removes a user from
github due to automated bot detection).
Also concerning the lua updater, we pin some of the dependencies, and I
would like to be able to unpin the package without editing the csv
(coming in later PRs).
* doc/updaters: update command to update editor plugins
including vim, kakoune and lua packages
Co-authored-by: figsoda
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.
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"
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.
Fixed a few grammatical issues. Was uncertain how to address Treesitter, as the homepage itself is inconsistent, using all combinations of Treesitter, Tree-sitter, treesitter and tree-sitter.
Sometimes I want to pass a different implementation of `mkNugetDeps`.
For example in private repos, it can be handy to use `__noChroot = true`
and bypass the deps.nix generation altogether. Or some Nuget packages
ship with ELF binaries that need to be patched, and that's best done as
soon as possible.
