I did double-check that the fixed version does what we would want. In
either case, the katamari script is mostly of historical value, and
there's nothing to change in pkgs.
I tested the shell snippets shown here; they work. Note that, because
they're intended for copy-and-paste, I did *not* make them into
ShellSessions with prompts. But that's something I can do if desired.
Each invocation of pkgs.extends adds 130MB of allocation to the hydra
evaluator. We are already struggling with the amount of memory nixpkgs
requires.
`pkgs.extend` is a useful escape-hatch, but should be not be used inside
of nixpkgs directly.
This is essentially an automatic pandoc conversion of the weechat
section in docbook as part of the larger CommonMark Docs project
(https://github.com/NixOS/nixpkgs/projects/37)
fixes#105264
Update doc/builders/packages/weechat.section.md
Co-authored-by: Frederik Rietdijk <freddyrietdijk@fridh.nl>
Update doc/builders/packages/weechat.section.md
Co-authored-by: Jan Tojnar <jtojnar@gmail.com>
* Updated QT section
* Fixed trailing whitespace
* Update doc/languages-frameworks/qt.section.md
Co-authored-by: Jan Tojnar <jtojnar@gmail.com>
* Update doc/languages-frameworks/qt.section.md
Co-authored-by: Jan Tojnar <jtojnar@gmail.com>
* Made changes to docs as per jtojnar's review
* Added docbook tags for callouts back in
Co-authored-by: Jan Tojnar <jtojnar@gmail.com>
With the addition of ruby.withPackages, manveru rewrote the nixpkgs
manual section for the ruby language but did not add it to the manual.
This commit replaces the previous documentation with manveru's updated
version.
Adding them to `maintainers/maintainer-list` in a separate commit.
Co-Authored-By: Pavol Rusnak <pavol@rusnak.io>
Co-Authored-By: Atemu <atemu.main@gmail.com>
Co-Authored-By: Kevin Cox <kevincox@kevincox.ca>
Add nice markdown documentation for how to use mvn2nix plugin and the
buildMaven function within nixpkgs.
Update doc/languages-frameworks/maven.md
Co-authored-by: Robert Hensing <roberth@users.noreply.github.com>
Apply suggestions from code review
Co-authored-by: Doron Behar <doron.behar@gmail.com>
Apply suggestions from code review
Co-authored-by: Doron Behar <doron.behar@gmail.com>
Apply suggestions from code review
Co-authored-by: Doron Behar <doron.behar@gmail.com>
The previous implementation of plugin-support for the kakoune derivation
was based on generating, at build time, a `plugins.kak` file that would
source all .kak files in the list of plugins, and wrap the `kak` binary
in a script that would add some command-line arguments so that this
file gets loaded on start-up. The main problem with this approach
is that the plugins' code get executed *after* the user's configuration
file is loaded, so effectively one cannot automatically activate/configure
these plugins.
The idiomatic way of loading plugins is ensuring they end up installed
somwhere under `share/kak/autoload`. Because plugins are already being
packaged to have their code in `share/kak/autoload/plugins/<name-of-plugin>`,
we can obtain a derivation that includes the plugins simply by doing a
`symlinkJoin` of `kakoune-unwrapped` and all the requested plugins.
For this to work, we need to fix two issues:
1. By default, kakoune makes `share/kak/autoload` a symbolic link to
`share/kak/rc`, which contains all builtin definitions. We need
to patch this to put the symlink under `share/kak/autoload/rc`, so that
the join works.
2. By default kakoune expects the `autoload` directory to be in
`../share/kak/autoload` relative to the location of the `kak` binary.
We need to set the `KAKOUNE_RUNTIME` to point the symlinked
share/kak for this to work.
