The main motivation for this is to have something to google for LD=$CC.
Eventually, this should probably be moved to another section, but we
can deal with that later.
1. Call `nix-build` with `--no-out-link` to avoid cluttering the source dir.
2. Re-add `patchShebangs`, since `buildCommand` doesn't imply a patch phase. (It was my fault to remove this in the first place, sorry!)
This allows one to always override the call to `buildPythonPackage`.
In the following example we create an environment where we have the `blaze` package using an older version of `pandas`. We override first the Python interpreter and pass `packageOverrides` which contains the overrides for packages in
the package set.
```
with import <nixpkgs> {};
(let
python = let
packageOverrides = self: super: {
pandas = super.pandas.overridePythonPackage(old: rec {
version = "0.19.1";
name = "pandas-${version}";
src = super.fetchPypi {
pname = "pandas";
inherit version;
sha256 = "08blshqj9zj1wyjhhw3kl2vas75vhhicvv72flvf1z3jvapgw295";
};
});
};
in pkgs.python3.override {inherit packageOverrides;};
in python.withPackages(ps: [ps.blaze])).env
```
1. 'wrapper' has been renamed to 'wrappedRuby', so use this instead.
2. mkDerivation isn't called with a 'src' attribute, so skip the 'unpackPhase' to avoid an error.
3. Simplify the build command. 'mkdir' and 'patchShebangs' don't need to be called explicitly.
So that helper scripts can be easily sourced in interactive shell
configuration. `autojump` package was already present and had the same
requirements for findind a `share` folders, so I took an inspiration
there.
I beleive this is a better alternative to:
- https://github.com/NixOS/nixpkgs/pull/25080
- https://github.com/NixOS/nixpkgs/pull/27058
Replacing `$out/share/shell` with `$bin/share/fzf` was necessary to
prevent dependency loop in produced derivations.
Packages get --host and --target by default, but can explicitly request
any subset to be passed as needed. See docs for more info.
rustc: Avoid hash breakage by using the old (ignored)
dontSetConfigureCross when not cross building
Improve beam docs:
* correct spelling
* update per pandoc changes
* capitalize titles
* capitalize BEAM throughout and use "the BEAM" when referring to the virtual machine.
* tweak grammar and phrasing
* reformat build-tools-rebar3 section
* add more links
* re-wrap <para>s
Also update <programlisting>s
* normalize whitespace
* don't double quote homepage
* use $ in all shell snippets
The documentation got a bit stale compared to actual contents of
nixpkgs. This commit focuses on updating existing docs, not on making
sure all details of beam packages are covered.
This section gives some details on how to setup an "environment"
without having to go through NixOS (although it could be used there
too). I’ve tried to make it straightforward and have a kind of
"tutorial" feel. Not sure if that’s appropriate for the manual, so any
recommended changes would be helpful.
This gives some basics on configuring Emacs within Nix. The
configuration is fairly long just to give a good idea of what’s going
on. I can trim out some of it if it’s not necessary. Note that there
is already a section for Emacs in the NixOS manual. However, this is
aimed at avoiding using modules altogether to make things easier for
non-NixOS users. This configuration should work on NixOS anyway,
however.
Fixes#24243Fixes#19956
Each bootstrapping stage ought to just depend on the previous stage, but
poorly-written compilers break this elegence. This provides an easy-enough
way to depend on the next stage: targetPackages. PLEASE DO NOT USE IT
UNLESS YOU MUST!
I'm hoping someday in a pleasant future I can revert this commit :)
* Update python.md
this makes it clear how to alter `attributes` by using `packageOverrides`
* Update python.md
* Update python.md
* Update python.md
* Update python.md
* Update python.md
* Update python.md
Fix code syntax highlighting by specifying language in every code block
and adding some context to Nix code blocks to make them valid
expressions. Use the same markup style for all code blocks. Reformat
some code blocks.
fixes#23535
- Describe the new `libsForQt5.callPackage` interface
- Emphasize that Qt dependencies must be imported unqualified
- Describe the new `kdeWrapper` wrapper generator
If a package's meta has `knownVulnerabilities`, like so:
stdenv.mkDerivation {
name = "foobar-1.2.3";
...
meta.knownVulnerabilities = [
"CVE-0000-00000: remote code execution"
"CVE-0000-00001: local privilege escalation"
];
}
and a user attempts to install the package, they will be greeted with
a warning indicating that maybe they don't want to install it:
error: Package ‘foobar-1.2.3’ in ‘...default.nix:20’ is marked as insecure, refusing to evaluate.
Known issues:
- CVE-0000-00000: remote code execution
- CVE-0000-00001: local privilege escalation
You can install it anyway by whitelisting this package, using the
following methods:
a) for `nixos-rebuild` you can add ‘foobar-1.2.3’ to
`nixpkgs.config.permittedInsecurePackages` in the configuration.nix,
like so:
{
nixpkgs.config.permittedInsecurePackages = [
"foobar-1.2.3"
];
}
b) For `nix-env`, `nix-build`, `nix-shell` or any other Nix command you can add
‘foobar-1.2.3’ to `permittedInsecurePackages` in
~/.config/nixpkgs/config.nix, like so:
{
permittedInsecurePackages = [
"foobar-1.2.3"
];
}
Adding either of these configurations will permit this specific
version to be installed. A third option also exists:
NIXPKGS_ALLOW_INSECURE=1 nix-build ...
though I specifically avoided having a global file-based toggle to
disable this check. This way, users don't disable it once in order to
get a single package, and then don't realize future packages are
insecure.
