| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
|
|
|
|
Reflects the recent changes to the lua infrastructure.
Packaging from luarocks should be encouraged.
|
|
|
|
|
|
...for rust-packages (into staging)
|
|
Note this also means python3Minimal is now also Python 3.8.
This reverts commit eb1369670b5a4e616ff0cf4100616479b1fa3064 and adds more.
|
|
validatePkgConfig: init
|
|
|
|
* Add id
* Mention rpath
* The control variables do not really have to be env vars (though without structuredAttrs there is not a difference)
|
|
Co-authored-by: cole-h <cole.e.helbling@outlook.com>
Co-authored-by: asymmetric <lorenzo@mailbox.org>
|
|
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.
|
|
currently LTS 12.x and Current 14.x
|
|
Signed-off-by: Christian Albrecht <christian.albrecht@mayflower.de>
|
|
See also https://discourse.nixos.org/t/rust-build-speed-improvements/7225
|
|
Agda expects a "depend" (not "depends") field in the library description.
|
|
* python3Packages.venvShellHook: add postVenvCreation
* python: docs: add postVenvCreation explaination
|
|
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.
|
|
Agda rework
|
|
|
|
|
|
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`.
|
|
Improvement suggested in #87094
|
|
|
|
|
|
gnome: document packaging icon themes
|
|
|
|
tarballs.nixos.org is omitted from the change because urls from there
are always hashed and checked
|
|
|
|
|
|
|
|
|
|
php.buildEnv: Make the exported php package overridable, improve handling of currently enabled extensions, etc
|
|
Since the introduction of php.unwrapped there's no real need for the
phpXXbase attributes, so let's remove them to lessen potential
confusion and clutter. Also update the docs to make it clear how to
get hold of an unwrapped PHP if needed.
|
|
This is useful if you need to access the dev output of the unwrapped
derivation.
|
|
Co-Authored-By: Jan Tojnar <jtojnar@gmail.com>
|
|
|
|
|
|
Rework withExtensions / buildEnv to handle currently enabled
extensions better and make them compatible with override. They now
accept a function with the named arguments enabled and all, where
enabled is a list of currently enabled extensions and all is the set
of all extensions. This gives us several nice properties:
- You always get the right version of the list of currently enabled
extensions
- Invocations chain
- It works well with overridden PHP packages - you always get the
correct versions of extensions
As a contrived example of what's possible, you can add ImageMagick,
then override the version and disable fpm, then disable cgi, and
lastly remove the zip extension like this:
{ pkgs ? (import <nixpkgs>) {} }:
with pkgs;
let
phpWithImagick = php74.withExtensions ({ all, enabled }: enabled ++ [ all.imagick ]);
phpWithImagickWithoutFpm743 = phpWithImagick.override {
version = "7.4.3";
sha256 = "wVF7pJV4+y3MZMc6Ptx21PxQfEp6xjmYFYTMfTtMbRQ=";
fpmSupport = false;
};
phpWithImagickWithoutFpmZip743 = phpWithImagickWithoutFpm743.withExtensions (
{ enabled, all }:
lib.filter (e: e != all.zip) enabled);
phpWithImagickWithoutFpmZipCgi743 = phpWithImagickWithoutFpmZip743.override {
cgiSupport = false;
};
in
phpWithImagickWithoutFpmZipCgi743
|
|
(#86051)"
For disabling tests when overriding, use `.overridePythonAttrs`.
Discussion about aliasing `.overridePythonAttrs` to `.overrideAttrs`.
https://github.com/NixOS/nixpkgs/pull/82772
This reverts commit 35812875a4455e2636eb24ddaf702faa4767fafa.
|
|
only very few people followed the strict policy in the last 5 years. the
maintainers accept backports without reason when it's obvious, so i
updated the policy to reflect that
|
|
|
|
|
|
|
|
BLAS/LAPACK fixup and expand docs
|
|
|
|
This adds some more information to the documentation as well as
addressing review from https://github.com/NixOS/nixpkgs/pull/85636.
|
|
|
|
BLAS/LAPACK fix fallout from #83888
|
|
This expands the documentation and explains how to assert LP64.
|
