Found using https://github.com/serokell/xrefcheck, which unfortunately
can't trivially be enforced in CI because we also have the manual markdown
files that need post-processing to be valid
Pscycopg2-binary is normally used in Python development to avoid having to build psycopg2 from source.
In nixpkgs we always want ot build from source whenever possible, but it can still be useful to provide a psycopg2-binary package.
This "fake" package exists to satisfy a dependency on psycopg2-binary, but still use the build from psycopg2.
cc @misuzu https://github.com/nix-community/pyproject.nix/issues/143
`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
This patch moves the code snippet which is shown as equivalent to the
example into the actual example block.
Visually, it was not easy to parse that the "equivalent" code piece
belonged to the code snippet that was hidden in the example (which is
collapsed by default).
By moving it into the example block, the "equivalent" piece is hidden by
default as well.
Signed-off-by: Matthias Beyer <mail@beyermatthias.de>
This was supposed to happen in #294504, but the commit was accidentally
left out when splitting off some libpq-related changes. Originated in
#179962, by Sandro.
Co-authored-by: Sandro Jäckel <sandro.jaeckel@gmail.com>
Co-authored-by: Wolfgang Walther <walther@technowledgy.de>
* vimPlugins: introduce passthru.initLua for some plugins
as described in https://github.com/NixOS/nixpkgs/issues/172538, some vim
plugins need some configuration to be able to work at all.
We choose not to patch those plugins and instead expose the necessary
configuration to make them work in `PLUGIN.passthru.initLua`.
For now the user can check if plugins have a `PLUGIN.passthru.initLua`
and if yes, prepend it to their own init.lua.
Maybe later we can revisit this to either patch them in a way that is
clear that it's a nixpkgs patch or by having the neovim wrapper pick
those snippets and autoadd them to init.lua ?
* Update doc/languages-frameworks/vim.section.md
Co-authored-by: Marc Jakobi <mrcjkb89@outlook.com>
---------
Co-authored-by: Marc Jakobi <mrcjkb89@outlook.com>
We haven't been good at managing expectations about this, so let's
tell people what level of support they can expect. I think the place
people are most likely to see it is the place where they learn about
overriding in the first place, so I've added it here.
Co-authored-by: Valentin Gagarin <valentin@gagarin.work>
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>
`lib.trivial.revisionWithDefault` will change with every Git commit, which causes the manual to be rebuilt on every since PR.
Using `nixpkgs.rev` (or the dummy value "master" if it's not present) means that the manual will contain the revision if built on Hydra, but will not otherwise.
Why?
1. https://hydra.nixos.org/jobset/nixos/trunk-combined#tabs-configuration shows that `pkgs/top-level/release.nix` is passed the `nixpkgs` attrset, which is a "Git checkout".
2. Git checkouts come from [`builtins.fetchGit`](https://nix.dev/manual/nix/2.18/language/builtins#builtins-fetchGit) and include the `rev` attribute.
3. The `rev` attribute is what `lib.trivial.revisionWithDefault` would have returned.
So, using `nixpkgs.rev or "master"` exclusively will cause the rebuilds on every commit to cease, but will allow "official" nixpkgs manual built on Hydra to continue to reference a specific commit.
every other format is deprecated, so to imply that people should be setting it is misleading
(`pyproject = true` should also go away eventually, but is the way until
then)
so that meta.description examples shown in the documentation
align with recommendations given in the "Meta attributes" section
in pkgs/README.md.
The changes were made with the following commands:
nix run nixpkgs#silver-searcher -- -l0 'description\s*=\s*"([Aa]n?|[Tt]he)\s' doc \
| xargs -0 nix run nixpkgs#gnused -- -i '' -Ee '/description/s/"([Aa]n?|[Tt]he)\s(.)/"\U\2/'
nix run nixpkgs#silver-searcher -- -l0 'description\s*=\s*".*\."' doc \
| xargs -0 nix run nixpkgs#gnused -- -i '' -Ee '/description/s/\."/"/'
Problem: `nix-build doc` gives a bunch of warnings because it inspects
`lib` to figure out where all the symbols are.
Solution: Move the step of figuring out where the symbols are to
a Nix evaluation inside a derivation instead.
Running the `update.py` script directly doesn't work anymore, so instead
replace all usages of it in the documentation with `nix-shell -p
vimPluginsUpdater --run 'vim-plugins-updater'`.
`mkComposerRepository` required `pname` and `version` since the beginning
(b36ad2f517), with the boolean attribute
becoming required later (3eb168da92).
For whatever reason `zip` in this case doesn't seem to be respecting the
`$TMP` or `$TMPDIR` variables, resulting in a permission denied error on
Darwin when sandbox is enabled.
The `-b` flag allows one to manually specify a tempdir, which allows the
build to succeed in spite of sandboxing.
Fixes https://github.com/NixOS/nixpkgs/issues/326380
This commit introduces two new properties:
`enable` and `type`, to replace the `enabled` property.
`enable` has the same meaning as is common across nixpkgs.
`type` has the same meaning as the existing `enabled` property.
`enabled` property is now deprecated and will be removed in a future release.
Fixes #180654
`meta.sourceProvenance` has its own level 2 heading at the bottom of the file,
but unlike the other meta-attributes it doesn't have a level 3 heading under the
"Standard meta-attributes" section. Readers looking at the list of subheadings
directly under the "Standard meta-attributes" section header may not realize
that `meta.sourceProvenance` exists unless they scroll down to the bottom of the
page.
This commit adds a level 3 heading for sourceProvenance under "Standard
meta-attributes".
