We keep running into situations where we can't get the right
combination of rustc flags through build systems into rustc.
RUSTFLAGS is the only variable supported across build systems, but if
RUSTFLAGS is set, Cargo will ignore all other ways of specifying rustc
flags, including the target-specific ones, which we need to make
dynamic musl builds work. (This is why pkgsCross.musl64.crosvm is
currently broken — it works if you unset separateDebugInfo, which
causes RUSTFLAGS not to be set.)
So, we need to do the same thing we do for C and C++ compilers, and
add a compiler wrapper so we can inject the flags we need, regardless
of the build system.
Currently the wrapper only supports a single mechanism for injecting
flags — the NIX_RUSTFLAGS environment variable. As time goes on,
we'll probably want to add additional features, like target-specific
environment variables.
While the word 'simply' is usually added to encourage readers, it often has the
opposite effect and may even appear condescending, especially when the reader
runs into trouble trying to apply the suggestions from the documentation. It is
almost always an improvement to simply drop the word from the sentence.
(there are more possible improvements like this, we can apply those in separate
PRs)
Replaced with python3Packages except for the following to avoid misuse of pythonPackages
1. which we need for the explanation
2. which are replaced by python3Packages as variables
* luarocks-packages-updater: init
Goal is to make it possible to maintain out-of-tree luarocks packages
without needing to clone nixpkgs.
maintainers/scripts/update-luarocks-packages gets renamed to
pkgs/development/lua-modules/updater/updater.py
Once merged you can run for instance
nix run nixpkgs#luarocks-packages-updater -- -i contrib/luarocks-packages.csv -o contrib/generated-packages.nix
I also set the parallelism (--proc) to 1 by default else luarocks fails
because of https://github.com/luarocks/luarocks/issues/1540
* Update maintainers/scripts/pluginupdate.py
Co-authored-by: Marc Jakobi <mrcjkb89@outlook.com>
---------
Co-authored-by: Marc Jakobi <mrcjkb89@outlook.com>
The nixpkgs documentation mentions how to update out of tree plugins but
one problem is that it requires a nixpkgs clone.
This makes it more convenient.
I've had the need to generate vim plugins and lua overlays for other
projects unrelated to nix and this will make updates easier (aka just
run `nix run nixpkgs#vimPluginsUpdater -- --proc=1` or with the legacy commands:
`nix-shell -p vimPluginsUpdater --run vim-plugins-updater`.
I added an optional "nixpkgs" argument to command line parser, which is the path
towards a nixpkgs checkout. By default the current folder.
update-luarocks-packages: format with black
Allows splicing to work correctly
from issue 211340
>> 3: Discourage using package sets like python3.pkgs "directly"
> I think about 8 years ago I introduced this and it has been a clear mistake. Since then this pattern was copied throughout. We should indeed go to pythonPackages and also move the helpers such as buildEnv and withPackages into the package set, like haskell already had before.
- FRidh
This change which involves creating multiple outputs for CUDA
redistributable packages.
We use a script to find out, ahead of time, the outputs each redist
package provides. From that, we are able to create multiple outputs for
supported redist packages, allowing users to specify exactly which
components they require.
Beyond the script which finds outputs ahead of time, there is some custom
code involved in making this happen. For example, the way Nixpkgs
typically handles multiple outputs involves making `dev` the default
output when available, and adding `out` to `dev`'s
`propagatedBuildInputs`.
Instead, we make each output independent of the others. If a user wants
only to include the headers found in a redist package, they can do so by
choosing the `dev` output. If they want to include dynamic libraries,
they can do so by specifying the `lib` output, or `static` for static
libraries.
To avoid breakages, we continue to provide the `out` output, which
becomes the union of all other outputs, effectively making the split
outputs opt-in.
1. Clarify what is the reason for importing and to where it saves
2. Clarify that packages.sqlite is a temporary file
3. Link to section about native dependencies from first mention of ql.nix
* nixpkgs manual, doc Python: render interpreters in a table
The current paragraph presenting Python interpreters is verbose and hinders clarity. The information provided is well suited to be rendered as a table.
Co-authored-by: Shahar "Dawn" Or <mightyiampresence@gmail.com>
* nixpkgs manual, doc Python: fix typos in interpreters' table
* nixpkgs manual, doc Python: update header in interpreters' table
* nixpkgs manual, doc Python: get rid of empty block code workaround in interpreters' table
---------
Co-authored-by: Shahar "Dawn" Or <mightyiampresence@gmail.com>
Conflicts:
- pkgs/tools/networking/shadowfox/default.nix between e989daa65f and 1c29673fcc
- pkgs/tools/networking/wuzz/default.nix between 7d80417710 and 1c29673fcc
In 787af0f79f
I had to change ${go-modules} to $goModules to allow overrideAttrs to work;
However, env vars cannot contain -, so i had to change go-modules too.
This in turn broke nix-update because it uses the go-modules attr.
Instead of making nix-update more complicated, make go-modules naming match cargoDeps.
`fd --type f | xargs sd '\bgo-modules\b' 'goModules'`
and revert change to pkgs/applications/misc/dstask/default.nix
and pkgs/servers/http/dave/default.nix
and pkgs/os-specific/darwin/plistwatch/default.nix
release note added
also updates nixdoc to 2.3.0. the nixdoc update is not a separate commit
because that would leave the manual build broken for one commit,
potentially breaking bisects and rebases.
This is actually relatively complicated to achieve, since it involves
overriding GHC on e.g. aarch64-darwin, so the FAQ entry seems warranted.
It's also a good exercise to me, since it demonstrates some problems
with the overriding infrastructure, i.e. that it has a tendency to
inherit the pkgs fixpoint from prev. An example of this problem is
https://github.com/NixOS/nixpkgs/issues/235960, but it has different
manifestations as well. Awareness of this will also help writing the
other sections on overriding.
How complicated it is, seems to be further incentive to go ahead with
https://github.com/NixOS/nixpkgs/pull/239548 as well.
nixos-render-docs does not support this, and since the examples are
small there isn't that much value in callouts here. change them to
simple MD code blocks and lists instead.
skipping heading levels (eg from # to ###, or starting at ###) is legal
in pandoc, but not in nixos-render-docs. pandoc acts as though section
levels *were* consecutive, nixos-render-docs prefers to tell people not
to do that kind of thing because it can make documents more fragile.
Updates all interpreter references with 3.10/3.11, which are the
current version, that we recurse into for their package set.
Update all code examples with an explicit `format` and expand lists
with multiple items as we do in the python package set. Also set
`pythonImportsCheck` where tests are disabled.
* 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.
