One issue with cargoSha256 is that it's hard to detect when it needs to
be updated or not. It's possible to upgrade a package and forget to
update cargoSha256 and run with old versions of the program or
libraries.
This commit introduces `verifyCargoDeps` which, when enabled, will check
that the Cargo.lock is not out of date in the cargoDeps by comparing it
with the package source.
This commit splits the `buildPythonPackage` into multiple setup hooks.
Generally, Python packages are built from source to wheels using `setuptools`.
The wheels are then installed with `pip`. Tests were often called with
`python setup.py test` but this is less common nowadays. Most projects
now use a different entry point for running tests, typically `pytest`
or `nosetests`.
Since the wheel format was introduced more tools were built to generate these,
e.g. `flit`. Since PEP 517 is provisionally accepted, defining a build-system
independent format (`pyproject.toml`), `pip` can now use that format to
execute the correct build-system.
In the past I've added support for PEP 517 (`pyproject`) to the Python
builder, resulting in a now rather large builder. Furthermore, it was not possible
to reuse components elsewhere. Therefore, the builder is now split into multiple
setup hooks.
The `setuptoolsCheckHook` is included now by default but in time it should
be removed from `buildPythonPackage` to make it easier to use another hook
(curently one has to pass in `dontUseSetuptoolsCheck`).
This is a new package that provides a shell hook to make it easy to
declare manpages and shell completions in a manner that doesn't require
remembering where to actually install them. Basic usage looks like
{ stdenv, installShellFiles, ... }:
stdenv.mkDerivation {
# ...
nativeBuildInputs = [ installShellFiles ];
postInstall = ''
installManPage doc/foobar.1
installShellCompletion --bash share/completions/foobar.bash
installShellCompletion --fish share/completions/foobar.fish
installShellCompletion --zsh share/completions/_foobar
'';
# ...
}
See source comments for more details on the functions.
This setup hook modifies a Perl script so that any "-I" flags in its shebang
line are rewritten into a "use lib ..." statement on the next line. This gets
around a limitation in Darwin, which will not properly handle a script whose
shebang line exceeds 511 characters.
This system type was previously broken but is now fixed.
Add it here to showcase the common task of launching a fully-fledged Android
system with an included app store.
New release available:
https://www.citrix.com/downloads/workspace-app/linux/workspace-app-for-linux-latest.html
Apart from the new version the following things changed:
* Updated the docs as all notes about `citrix_receiver` also apply for
`citrix_workspace`. Also added a deprecation warning about the
upcoming removal.
* Removed the `libidn_134` override as neither `citrix_workspace_19_3_0`
nor `citrix_workspace_19_6_0` require this library anymore according
to `readelf -d ./result/opt/citrix-icaclient/wfica` (in contrast to
`citrix_receiver_13_10_0`).
* Added myself as maintainer as well.
Motivation: There is a thriving plugin ecosystem for Kakoune now,
and it is nice to add these in our Nix configurations. This was modeled
on neovim's plugins.
parinfer-rust is useable both standalone and as a Kakoune plugin,
so the plugin file inherits the same definition as pkgs.
I'll make PRs for other plugins if this gets accepted.
[Here](https://github.com/eraserhd/nixpkgs/tree/kak-ansi)'s a tested
branch for the `kak-ansi` plugin.
* manual: rename to users and contributors manual, add some user notes that should be there but don't fit in any chapter
* manual: move the package notes that are completely usage-related to the upper user notes section
* manual: link to package-specific development notes from user notes
With remote builds, the sandbox can't be accessed by `cntr` as it is on
a different machine. I decided to put this into an extra `note` block as it took
me admittedly too much time to figure this out.
There was a bunch of stuff in the cross section that haddn't had any
attention in a while. I might need to slim it down later, but this is
good for now.
$(shell ...) looks a little sketch like it will be run no matter what.
And there are problems building the manual on darwin so hopefully this
fixes them.
The function buildGoModule builds Go programs managed with Go modules. It builds
a Go module through a two phase build:
- An intermediate fetcher derivation. This derivation will be used to
fetch all of the dependencies of the Go module.
- A final derivation will use the output of the intermediate derivation
to build the binaries and produce the final output.
Especially older hardware doesn't support AVX instructions. DLib is
still functional there, but significantly slower[1].
By setting `avxInstructions` to false, DLib will be compiled without
this feature.
[1] http://dlib.net/compile.html
Whenever we create scripts that are installed to $out, we must use runtimeShell
in order to get the shell that can be executed on the machine we create the
package for. This is relevant for cross-compiling. The only use case for
stdenv.shell are scripts that are executed as part of the build system.
Usages in checkPhase are borderline however to decrease the likelyhood
of people copying the wrong examples, I decided to use runtimeShell as well.
The appimageTools attrset contains utilities to prevent
the usage of appimage-run to package AppImages, like done/attempted
in #49370 and #53156.
This has the advantage of allowing for per-package environment changes,
and extracts into the store instead of the users home directory.
The package list was extracted into appimageTools to prevent
duplication.
Since #53055 was merged the Makefile for the manual could not be run
correctly as the generated function documentation was included, but
not actually generated.
This adds the necessary generation step by first building the XML file
containing function locations and preserving its store path in a
variable, which is then used both for linking of the locations file
and as a build input for the function docs generator.
This fixes#55014
Comments on conflicts:
- llvm: d6f401e1 vs. 469ecc70 - docs for 6 and 7 say the default is
to build all targets, so we should be fine
- some pypi hashes: they were equivalent, just base16 vs. base32
This is useful when running tools like NixOps or nix-review
on workstations where the upload to the builder is significantly
slower then downloading the source on the builder itself.
We can't run the checkPhase when build != host, so we may as well make
the checkInputs native.
This signicantly improves the situation of Python packages when enabling
strictDeps.
Currently the manual scales to the view port of the browser.
This leads to an unreadable layout and I found myself
reading the xml source instead.
The optimal width would be around 50 characters per line.
Since we have code listings also in the manual I relaxed
this limit a bit towards 70 characters per line.
Modifies the build process of the manual to invoke nixdoc
automatically to generate XML files with function documentation.
Currently documentation is present for five of the files in `lib/`.
To add another file to the generated docs, both
`doc/functions/library.xml` and `doc/lib-function-docs.nix` must be
updated.
Since Intel's default openmp implementation is available in the same src
tarball, we can just include it in the package. This means that `mkl` now "just
works" without any environment variables, fragile setup-hooks, or forced
propagation.
Since the openmp implementation is only needed at runtime (and for test cases),
users can substitute a different one if they prefer by exporting it with
`LD_PRELOAD`, which is how Intel recommends handling this. If they do not do so,
`libiomp.so` lives next to `libmkl_rt.so` and thus will be in the RPATH as a
sane default.
Since this still comes from the same src tarball, we can ship it without losing
the fixed-output derivation; likewise, since Hydra is not building or caching
these, shipping these proprietary packages costs no bandwidth for the nix
community.
