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.
This is a mostly cosmetical commit, in the sense it doesn't change the contents
of any package, but reorganizes the overall Nixpkgs expressions.
Terminal emulators are an ubiquitous tool for any Unix user; even the beginners
are routinely familiarized to it. And, manifestly, there are many
implementations of terminal emulators out there, from those traditionally made
in C and C++ to those written in Haskell and Go.
Terminal emulators deserve more highlight. This commit does that by creating a
category for them.
I made a mistake merge. Reverting it in c778945806 undid the state
on master, but now I realize it crippled the git merge mechanism.
As the merge contained a mix of commits from `master..staging-next`
and other commits from `staging-next..staging`, it got the
`staging-next` branch into a state that was difficult to recover.
I reconstructed the "desired" state of staging-next tree by:
- checking out the last commit of the problematic range: 4effe769e2
- `git rebase -i --preserve-merges a8a018ddc0` - dropping the mistaken
merge commit and its revert from that range (while keeping
reapplication from 4effe769e2)
- merging the last unaffected staging-next commit (803ca85c20)
- fortunately no other commits have been pushed to staging-next yet
- applying a diff on staging-next to get it into that state
Teach installShellCompletion how to install completions from a named
pipe. Also add a convenience flag `--cmd NAME` that synthesizes the name
for each completion instead of requiring repeated `--name` flags.
Usage looks something like
installShellCompletion --cmd foobar \
--bash <($out/bin/foobar --bash-completion) \
--fish <($out/bin/foobar --fish-completion) \
--zsh <($out/bin/foobar --zsh-completion)
Fixes#83284
Move common attributes treated by both buildGoModule and buildGoPackage
to a separate section, out of the examples' "callouts".
Co-authored-by: zowoq <59103226+zowoq@users.noreply.github.com>
This hook moves systemd user service file from `lib/systemd/user` to
`share/systemd/user`. This is to allow systemd to find the user
services when installed into a user profile. The `lib/systemd/user`
path does not work since `lib` is not in `XDG_DATA_DIRS`.
Pull #89453 introduced a bug in the documentation that is preventing the
hydra build for nixpkgs-unstable from finishing. I have added the
additional option indroduced in that patch (runVend for go modules) and
added the callout tag so that the documenation can build again.
In #89806 it has been reported that the final package is missing a lot
of features like support for the self-service GUI and the
config-management.
While working on supporting those components in the Nix-package, I
decided to refactor the package to simplify the entire setup.
This patch changes the following things:
* Binaries and libraries are patched using the `autoPatchelfHook` to
avoid having unneeded libraries linked (e.g. some programs use gtk2,
others use gtk3).
* Moved source-declarations into their own file.
* Wrapped `configmgr` and `selfservice` and added those to `$out/bin`.
* Don't mention the old `citrix_receiver`-packages in the manual anymore
since those packages were removed in 19.09 and are EOLed anyways.
Closes#89806
/build/doc/manual-full.xml:12764:35: error: ID "build-phase" has already been defined
/build/doc/manual-full.xml:9029:33: error: first occurrence of ID "build-phase"
We no longer need it for most use cases so I am making it experimental.
I have something in mind where it might be useful in the future (customizing commit messages)
but for now, it would only confuse people.
Instead of having the updateScript support returning JSON object,
it should be sufficient to specify attrPath in passthru.updateScript.
It is much easier to use.
The former is now considered experimental.
Update scripts can now declare features using
passthru.updateScript = {
command = [ ../../update.sh pname ];
supportedFeatures = [ "commit" ];
};
A `commit` feature means that when the update script finishes successfully,
it will print a JSON list like the following:
[
{
"attrPath": "volume_key",
"oldVersion": "0.3.11",
"newVersion": "0.3.12",
"files": [
"/path/to/nixpkgs/pkgs/development/libraries/volume-key/default.nix"
]
}
]
and data from that will be used when update.nix is run with --argstr commit true
to create commits.
We will create a new git worktree for each thread in the pool and run the update
script there. Then we will commit the change and cherry pick it in the main repo,
releasing the worktree for a next change.
This adds the `validatePkgConfig` hook, which can be used to validate
pkg-config files in the output(s). Currently, this will just run
`pkg-config --validate` on all `.pc` files, capturing errors such as
the issue that was fixed in #87789.
The hook could be extended in the future with more fine-grained
checks.
Based on some feedback in #87094 and discussion with @fridh, this re-organizes
the onboarding tutorial in the Nixpkgs manual's python section, so that we start
with the simplest, most ad-hoc examples and work our way up. This progresses
from:
1. How to create an temporary python env at the cmdline, then
2. How to create a specific python env for a single script, then
3. How to create a specific python env for a project in a shell.nix, then
4. How to install a specific python env globally on the system or in a user profile.
Additionally, I've tried to standardize on some of the "best practice" ways of
doing things:
1. Instead of saying that this command style is "supported but strongly not
discouraged", I've just deleted it to avoid confusion.
Bad: nix-shell -p python38Packages.numpy python38Packages.toolz
Good: nix-shell -p 'python38.withPackages(ps: with ps; [ numpy toolz ])'
2. In the portion where we show how to add stuff to the user's
`XDG_CONFIG_HOME`, use overlays instead of `config.nix`. The former can do
everything the latter can do, but is also much more generic and powerful,
because it can compose with other files, compose with other envs, compose
with overlays that do things like swap whether tensorflow and pytorch are
built openblas/mkl/cuda stacks, and so on. The user is eventually going to
see the overlay, so to avoid confusion let's standardize on it.
An overlay by any other name would function just as well, but we generally use
`self: super:` for the regular overlays, and `python-self: python-super`.
