| Commit message (Collapse) | Author | Age |
|\
| |
| | |
Emscripten docs: reword and remove mention of `nix-env`
|
| |
| |
| |
| |
| |
| | |
that way the examples will also appear in the appendix
Co-authored by: Henrik Karlsson <i97henka@gmail.com>
|
| |
| |
| |
| |
| |
| | |
in particular, remove mention of `nix-env`
Co-authored by: Henrik Karlsson <i97henka@gmail.com>
|
| |
| |
| |
| |
| | |
lib.fakeSha256 results in `error: hash <fake_hash> does not include a
type, nor is the type otherwise known from context`.
|
|\ \
| | |
| | | |
Generate and refine documentation for `lib.customisation`
|
| | | |
|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
(#262137)
* doc/stdenv: rewrite manual build procedure to be closer to an auto-build
This is based on
<https://jade.fyi/blog/building-nix-derivations-manually/> plus some
more original research.
The previous version of this section did not work for your choice of
simple Haskell package, e.g. haskellPackages.hscolour, due to things
like `compileBuildDriverPhase` and other custom phases that it
does not address at all.
It seems more correct to use genericBuild in development to harmonize it
with what is actually done.
I feel a little bit like I am committing a sin by suggesting using the
experimental CLI in the manual (afaict I am the first to do this), but I
have given the old version of the command, and there are justifiable
reasons to do it:
* The noted limitations with env-vars are fixed. The one with the
non-empty temp directory was one I ran into myself and oh boy was that
not fun to debug.
* Additionally the outputs are set *before* sourcing `setup.sh`: there
is an issue with nix-shell where the original version of `$out` winds
up in `NIX_LDFLAGS` due to _addRpathPrefix, which means that resulting
executables may not run properly.
It is sad that `nix develop` propagates a wrong value of `SHELL` to
builders, though. It is equally sad that `nix-shell` is essentially
abandoned upstream, with undocumented and not insignificant differences
from `nix develop`.
For the exact script differences:
https://github.com/NixOS/nix/blob/17e6b85d05b3d32df244b1d4e89aa41fd8bdcae8/src/nix-build/nix-build.cc#L516-L551
https://github.com/NixOS/nix/blob/db026103b18fb8b5a719594502edd0f89eb9c268/src/nix/get-env.sh
Co-authored-by: Valentin Gagarin <valentin.gagarin@tweag.io>
|
|\ \ \
| | | |
| | | | |
buildFlutterApplication: Wrap buildDartApplication
|
| |/ /
| | |
| | |
| | |
| | |
| | | |
buildFlutterApplication
This allows Dart applications to benefit from the package override system, which is useful for things like FFI dependencies.
|
|/ / |
|
|\ \
| | |
| | | |
`darwin.linux-builder`: Make more observable
|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
I chose not to do nixos.{config, options} because that would make it
look too much like a configuration object, which it is not.
A configuration object I would define as for example the result of
calling NixOS, an attrset with `_type = "configuration";`.
Recreating a configuration object without evalModules is quite
feasible but not guaranteed to be correct, and not maintainable.
|
| | |
| | |
| | |
| | |
| | |
| | | |
Adds a basic FOD Fetcher for Bittorrent that uses Transmission as a client
Co-authored-by: Robert Hensing <roberth@users.noreply.github.com>
|
|\ \ \
| |/ /
|/| | |
doc manuals: add reference to nixos-render-docs
|
| | |
| | |
| | | |
Co-authored-by: Silvan Mosberger <github@infinisil.com>
|
| | | |
|
| | | |
|
|\ \ \
| | | |
| | | | |
buildNpmPackage: support makeWrapperArgs
|
| | | | |
|
| | | |
| | | |
| | | |
| | | | |
Co-authored-by: Lily Foster <lily@lily.flowers>
|
| | |/
| |/| |
|
|\ \ \ |
|
| |\ \ \ |
|
| | |/ /
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
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
|
|\| | | |
|
| |/ /
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
This commit adds minimal documentation of the supported platforms.
More exhaustive documentation would require producing a list of
platforms for each of the 7 tiers. This was attempted in #245368, but it
quickly became clear that that would be a long-term effort.
In the meantime, this commit adds the most important information to the
manual.
Co-authored-by: Valentin Gagarin <valentin.gagarin@tweag.io>
|
|\| | |
|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
* nixpkgs manual: add an alternative example in stdenv-separateDebugInfo
This change gets rid of the indirect reference to `nix-env -i` usage
and shows how to achieve the same goal with a shell expression.
Co-authored-by: Valentin Gagarin <valentin.gagarin@tweag.io>
|
|\| | |
|
| | | |
|
|\| | |
|
| | |
| | |
| | |
| | | |
the `from2Nix` suffix is a legacy from vim2nix but we dont use that anymore. It makes the name of the function unusual and long.
|
| | |
| | |
| | | |
`-z bindnow` doesn't exist. The actual flag added is `-z now`.
|
|\| | |
|
| | | |
|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
The text was originally added [0] following an apparently incomplete
research on how everything plays together. In fact, Nix propagates
`outputs` to the corresponding nested derivations, and there is some
messy behavior in Nixpkgs that only seems to propagate
`meta.outputsToInstall` in `buildEnv`[1].
This change moves the hints on how to use NixOS specifics to NixOS
module documentation (which is hopefully easier to find through
search.nixos.org), describes the default behavior in Nixpkgs (updating
a the link to the source), and removes the confusing mention of
`nix-env`.
the last of them should not be there to begin with. we don't want
beginners to use `nix-env`, as this is known to run them into trouble
eventually.
[0]: https://github.com/NixOS/nixpkgs/pull/76794
[1]: https://github.com/NixOS/nixpkgs/blob/1774d07242995050d2d8a91cb4da0855eac2e472/pkgs/build-support/buildenv/default.nix#L66
|
| |\ \
| | | |
| | | | |
python3Packages.flitBuildHook: remove
|
| | | | |
|
|\| | | |
|
| |/ /
| | |
| | |
| | |
| | | |
* nixpkgs manual: doc python: add hyperlinks to Python section
Co-authored-by: Valentin Gagarin <valentin.gagarin@tweag.io>
|
|\| | |
|
| | | |
|
|\| | |
|
| |\ \
| | | |
| | | | |
`lib.fileset.union`, `lib.fileset.unions`: init
|
| | | |
| | | |
| | | |
| | | | |
Also some minor formatting improvements
|
|\| | | |
|
| | | |
| | | |
| | | |
| | | |
| | | | |
Co-authored-by: Antoine du Hamel <duhamelantoine1995@gmail.com>
Co-authored-by: Sandro Jaeckel <sandro.jaeckel@gmail.com>
|
| | | | |
|
|/ / / |
|
|\ \ \
| | | |
| | | | |
rewrite `runCommand` interface docs
|