The dotnet sdk used usually needs to match the one required by the
project (global.json). Having the dependcy in nix just meant it always
had to be overridden.
Rationale:
With the advent of RFC 140, Nixpkgs becomes to promote self-contained package
directories and strongly discourages scattering along the old and deprecated
filesystem hierarchy.
Further, `build-support/flutter/*` is not referenced by any other expressions in
Nixpkgs besides flutter itself.
Further, concentrating all Flutter-related toolset below a same directory
hierarchy (arguably?) eases maintenance and future migrations.
Seeing the following new warnings pop up on stderr when cargo was bumped
to 1.78:
```
warning: `/build/.cargo/config` is deprecated in favor of `config.toml`
note: if you need to support cargo 1.38 or earlier, you can symlink `config` to `config.toml`
```
which happens to break commitmsgfmt builds in nix (#320294).
closes#320294
Tested the following packages with and without structuredAttrs:
- rust-analyzer: cargo-build-hook, cargo-check-hook
- jujutsu: cargo-nextest-hook
- kornia-rs: maturin-build-hook
For a long time, we've had `crossLibcStdenv`, `*Cross` libc attributes,
and `*bsdCross` pre-libc package sets. This was always bad because
having "cross" things is "not declarative": the naming doesn't reflect
what packages *need* but rather how we *provide* something. This is
ugly, and creates needless friction between cross and native building.
Now, almost all of these `*Cross` attributes are gone: just these are
kept:
- Glibc's and Musl's are kept, because those packages are widely used
and I didn't want to risk changing the native builds of those at this
time.
- generic `libcCross`, `theadsCross`, and friends, because these relate
to the convolulted GCC bootstrap which still needs to be redone.
The BSD and obscure Linux or freestnanding libcs have conversely all
been made to use a new `stdenvNoLibc`, which is like the old
`crossLibcStdenv` except:
1. It usable for native and cross alike
2. It named according to what it *is* ("a standard environment without
libc but with a C compiler"), rather than some non-compositional
jargon ("the stdenv used for building libc when cross compiling",
yuck).
I should have done this change long ago, but I was stymied because of
"infinite recursions". The problem was that in too many cases we are
overriding `stdenv` to *remove* things we don't need, and this risks
cyles since those more minimal stdenvs are used to build things in the
more maximal stdenvs.
The solution is to pass `stage.nix` `stdenvNoCC`, so we can override to
*build up* rather than *tear down*. For now, the full `stdenv` is also
passed, so I don't need to change the native bootstraps, but I can see
this changing as we make things more uniform and clean those up.
(adapted from commit 51f1ecaa59)
(adapted from commit 1743662e55)
I broke the usage of buildRustCrate with a toolchain from rust-overlay
when I added support for wasm32-unknown-unknown, this change adds
additional conditionals to restore the usage.
The toolchain can now be overriden either through
```
buildRustCrate {
rust = toolchain;
cargo = toolchain
}
```
or
```
buildRustCrate.override {
rustc = toolchain;
cargo = toolchain;
}
```
They should now be consistent with each other.
- stop binding attributes we don't care about (e.g. name, doCheck)
- remove attributes we handle in nix (e.g. useAppHost)
- inherit attributes with default values (e.g. packNupkg)
Unpacking to the build root was a bad idea. stdenv uses dumpVars() to
create a file env-vars containing the entire environment. This was
being installed in the derivation output, and since it contains lots of
store paths, it was bloating the closure for every nuget package.
After this change, enableParallelBuilding defaults to true for packages
using buildDotnetModule. The argument value already defaults to true,
but we did not use it. Note that default values in Nix are not present
in the arguments attribute set, e.g. `args` does not contain `def` for
`{ def ? true }@args: …` function unless this argument is explicitly
passed.
Previously, it wasn't possible to access the list of platforms we can
build Rust programs for outside of buildRustPackage. This was a
problem for packages that have optional Rust components, like
gstreamer or Meson, as there was no way to only build the Rust parts
for supported platforms. Now it's possible to get that information
from rustc's passthru.
Always specify the postPhases attribute as a list instead of a string.
Append elements to the postPhases Bash variable using appendToVar
instead of string or Bash array concatenation.
Always specify the preDistPhases attribute as a list instead of a string.
Append elements to the preDistPhases Bash variable using appendToVar
instead of string or Bash array concatenation.
Handle element insertion before a specific element using string
substitution as before, but handle both structured and unstructured
attributes.
Always specify the preConfigurePhases attribute as a list instead of a
string.
Append elements to the preConfigurePhases Bash variable using
appendToVar instead of string or Bash array concatenation.
Always specify the prePhases attribute as a list instead of a string.
Append elements to the prePhases Bash variable using appendToVar
instead of string or Bash array concatenation.
Before an overlay in the form of:
package.overrideAttrs (old: {
passthru = {};
})
would fail evaluation like:
error: attribute 'overrideModAttrs' missing
at /nix/store/afwc3m1sm49qq57xjv2hmd7iy4x0j33h-source/pkgs/build-support/go/module.nix:179:20:
178| outputHashAlgo = if finalAttrs.vendorHash == "" then "sha256" else null;
179| }).overrideAttrs finalAttrs.passthru.overrideModAttrs;
| ^
180|
Now instead we take the fallback default.
We should constrain the set of supported platforms to the platforms
supported by the compiler. Otherwise we run into the unfortunate
situation where setting meta.platforms in a Rust package to
platforms.unix or platforms.linux will reintroduce CPU architectures
unsupported by the compiler.
`importNpmLock.buildNodeModules` returns a derivation with a pre-built `node_modules` directory, as imported by `importNpmLock`.
This is to be used together with `importNpmLock.hooks.linkNodeModulesHook` to facilitate `nix-shell`/`nix develop` based development workflows:
```nix
pkgs.mkShell {
packages = [
importNpmLock.hooks.linkNodeModulesHook
nodejs
];
npmDeps = importNpmLock.buildNodeModules {
npmRoot = ./.;
inherit nodejs;
};
}
```
will create a development shell where a `node_modules` directory is created & packages symlinked to the Nix store when activated.
This code is adapted from https://github.com/adisbladis/buildNodeModules
Rationale: Since RFCs 140 and 146, the old category-based hierarchy is
deprecated and obsolete, and a new approach took place: packages should be as
self-contained as possible.
This paradigm is reflected in many new strict checks that prohibit a package to
refer to files outside its directory tree.
Following this spirit, this commit essentially moves nixpkgs
pkgs/test/default.nix to ./tests/default.nix.
Further, to keep the top-level `tests` attribute, a green alias is kept in the
place of older file.
There's no need to use a Nix file in the path here. By using a different
file we won't cause rebuilds when we change the Nix file, in particular
also when the Nix file is reformatted.
The previously used pattern was introduced in #318614, but technically
leaked the default flags into the global scope. While this would
probably not make much of a practical difference, making concatTo
support default values is a much cleaner approach.
This adds a new `imageStream` option that can be used in conjunction
with `pkgs.dockerTools.streamLayeredImage` so that the image archive
never needs to be materialized in the `/nix/store`. This greatly
improves the disk utilization for systems that use container images
built using Nix because they only need to store image layers instead of
the full image. Additionally, when deploying the new system and only
new layers need to be built/copied.
Currently we cannot debug rust binaries on darwin (via lldb).
The debug symbols seem to be provided by default in a number of files
in `target/debug/deps/*.rcgu.o`. As far as I can tell these have
hardcoded paths referring to the ephemeral build directory. However,
`split-debuginfo=packed` conveniently produces a `.dSYM` file that can
be copied to `$out/bin/` and immediately provide debugging information.
Fixes https://github.com/NixOS/nixpkgs/issues/262131
This envvar is also added to lib.proxyImpureEnvVars since it's
typically required for https proxies.
This change also updates fetchgit and go module fetching to use this
envvar. NIX_GIT_SSL_CAINFO is still supported for backwards
compatibility in fetchgit.
Since version 2.0.0, proc-macro-crate has assumed it can exec()
`env::var("CARGO")` in order to run `cargo locate-project`.
This commit adds a crate override to proc-macro-crate which simply writes the
path to buildPlatform.cargo into the proc-macro-crate sources.
This way we don't need to set `env.CARGO` for every build that depends on
proc-macro-crate -- if we do that, the $CARGO environment variable would be
visible to the entire build. This could potentially lead to incredibly
hard-to-troubleshoot heisenbugs if there is some other crate that expects
`env::var("CARGO")` to exist -- that other crate would mysteriously work only
in projects that use proc-macro-crate but not anywhere else!
Fixes two bugs:
- pass a forgotten `{}` to `compressDrv`.
- remove incorrect usage of `lndir` in `compressDrv`. I added a brief
comment on why, see [this comment][1] for more details.
Tested with:
```
$ nix build .#legacyPackages.x86_64-linux.gitea.passthru.data-compressed
$ ls -lh result/public/assets/licenses.txt*
lrwxrwxrwx 1 root root 90 Jan 1 1970 result/public/assets/licenses.txt -> /nix/store/p21irsr57hckd3x3ym18aa0cr9zmm3an-gitea-1.22.1-data/./public/assets/licenses.txt
-r--r--r-- 1 root root 30K Jan 1 1970 result/public/assets/licenses.txt.br
-r--r--r-- 1 root root 82K Jan 1 1970 result/public/assets/licenses.txt.gz
```
[1]: https://github.com/NixOS/nixpkgs/pull/332752#discussion_r1721043286
String-interpolation converts path objects inside `contents` into store
paths to ensure they are properly included in the result image.
See tests.trivial-builders.references for the necessity of
string-interpolation.
Quote each string-interpolated content member to accomodates spaces
inside.
Was trying out the recommended example for `writePython3Bin` and it
failed with:
```
Traceback (most recent call last):
File "/nix/store/gcmhfm7mslpndjasfhvs66f1ca24vxim-test_py3/bin/test_py3", line 4, in <module>
y = yaml.load("""
TypeError: load() missing 1 required positional argument: 'Loader'
```
Looks like `yaml.load(input)` was deprecated in 5.1: https://msg.pyyaml.org/load
`nixos-24.05` uses `6.0.1` so we're in the clear.
* autoPatchelfHook: add keep_libc flag
- Add keep_libc flag to disable the default libc handling. Intended
to be used by systemd.
- Add autoPatchelfFlags to autoPatchelfHook for passing arguments to
the autoPatchelf script
This reverts part of the change made in #307068 / 80be926.
Fixes#332533
Fix overriding of vendorHash and various attributes via the fixed point
attribute support of stdenv.mkDerivation.
Pass as derivation attributes
goModules, modRoot, vendorHash, deleteVendor, and proxyVendor.
Move goModules and vendorHash out of passthru.
Co-authored-by: Doron Behar <doron.behar@gmail.com>
Place the VM disk image in a local directory "disk-image" instead of
"$out", so that we don't have to delete it to reserve "$out" for the
container image.
