the `devmode` helper made for the Nixpkgs/NixOS manual was exposed wrapped
in `mkShell`, which made it impossible to reuse.
this change strips that wrapper and reproduces it at the call site.
now one can use `devmode` from anywhere Nixpkgs is available:
devmode = pkgs.callPackage "${pkgs.path}/pkgs/tools/nix/web-devmode.nix" {
buildArgs = toString ./.;
open = "/index.html";
};
We are migrating packages that meet below requirements:
1. using `callPackage`
2. called path is a directory
3. overriding set is empty (`{ }`)
4. not containing path expressions other than relative path (to
makenixpkgs-vet happy)
5. not referenced by nix files outside of the directory, other
than`pkgs/top-level/all-packages.nix`
6. not referencing nix files outside of the directory
7. not referencing `default.nix` (since it's changed to `package.nix`)
8. `outPath` doesn't change after migration
The tool is here: https://github.com/Aleksanaa/by-name-migrate.
Changelog:
* bash: Add shell completion for `nom` command (thanks to @tomberek and @pdietl).
* zsh: Add shell completion for `nom` and `nom-shell` command (additionally to the existing completion for `nom-build`).
* Fix typo in README (thanks to @techie2000)
In preparation for the deprecation of `stdenv.isX`.
These shorthands are not conducive to cross-compilation because they
hide the platforms.
Darwin might get cross-compilation for which the continued usage of `stdenv.isDarwin` will get in the way
One example of why this is bad and especially affects compiler packages
https://www.github.com/NixOS/nixpkgs/pull/343059
There are too many files to go through manually but a treewide should
get users thinking when they see a `hostPlatform.isX` in a place where it
doesn't make sense.
```
fd --type f "\.nix" | xargs sd --fixed-strings "stdenv.is" "stdenv.hostPlatform.is"
fd --type f "\.nix" | xargs sd --fixed-strings "stdenv'.is" "stdenv'.hostPlatform.is"
fd --type f "\.nix" | xargs sd --fixed-strings "clangStdenv.is" "clangStdenv.hostPlatform.is"
fd --type f "\.nix" | xargs sd --fixed-strings "gccStdenv.is" "gccStdenv.hostPlatform.is"
fd --type f "\.nix" | xargs sd --fixed-strings "stdenvNoCC.is" "stdenvNoCC.hostPlatform.is"
fd --type f "\.nix" | xargs sd --fixed-strings "inherit (stdenv) is" "inherit (stdenv.hostPlatform) is"
fd --type f "\.nix" | xargs sd --fixed-strings "buildStdenv.is" "buildStdenv.hostPlatform.is"
fd --type f "\.nix" | xargs sd --fixed-strings "effectiveStdenv.is" "effectiveStdenv.hostPlatform.is"
fd --type f "\.nix" | xargs sd --fixed-strings "originalStdenv.is" "originalStdenv.hostPlatform.is"
```
This is a rare case of a Nix file actually ending up in the build result.
We reformat this now, causing a rebuild, so that we won't cause a rebuild
in the treewide reformatting PR.
With: cargo update time --recursive
It turns out that in this case a simple `cargo update time` is
not enough to fix the build; one also needs to add the `--recursive`
flag.
This focuses on Rust packages, since the most commonly used argument
parser library (clap/structopt) makes the following pattern natural and
thus common:
postInstall = ''
installShellCompletion --cmd foo \
--bash <($out/bin/foo completion bash) \
…
This commit just guards those with
lib.optionalString (stdenv.buildPlatform.canExecute stdenv.hostPlatform)
splitting the string where unrelated actions are performed.
Otherwise references to the Python interpreter inside the set are wrong, as demonstrated by:
``` nix
with import <nixpkgs> { };
let
python' = python3.override {
packageOverrides = final: prev: { requests = prev.requests.overridePythonAttrs(old: { version = "1337"; }); };
};
in python'.pkgs.python.pkgs.requests
```
which returns the _non_ overriden requests.
And the same with `self`:
```
with import <nixpkgs> { };
let
python' = python3.override {
self = python';
packageOverrides = final: prev: { requests = prev.requests.overridePythonAttrs(old: { version = "1337"; }); };
};
in python'.pkgs.python.pkgs.requests
```
which returns the overriden requests.
This can manifest itself as file collisions when constructing environments or as subtly incorrect dependency graphs.
Lore overrides have been included with binlore's source up to now, but
this hasn't worked very well. (It isn't as easy to self-service for
people working in nixpkgs, and its use of partial pnames for matching
breaks down around some edge cases like version numbers appearing
early in perl pnames, or multiple packages having identical pnames.)
This is done with the following bash script:
```
#!/usr/bin/env bash
process_line() {
local filename=${1%:}
if [[ $4 =~ \"(.*)\"\; ]]; then
local sha256="${BASH_REMATCH[1]}"
fi
[[ -z $sha256 ]] && return 0
local hash=$(nix hash to-sri --type sha256 $sha256)
echo "Processing: $filename"
echo " $sha256 => $hash"
sed -i "s|cargoSha256 = \"$sha256\"|cargoHash = \"$hash\"|"
$filename
}
# split output by line
grep -r 'cargoSha256 = ' . | while IFS= read -r line; do
# split them further by space
read -r -a parts <<< "$line"
process_line "${parts[@]}"
done
```
