This provides a means to build a PHP package based on a list of
extensions from another.
For example, to generate a package with all default extensions
enabled, except opcache, but with ImageMagick:
php.withExtensions (e:
(lib.filter (e: e != php.extensions.opcache) php.enabledExtensions)
++ [ e.imagick ])
So now we have only packages for human interaction in php.packages and
only extensions in php.extensions. With this php.packages.exts have
been merged into the same attribute set as all the other extensions to
make it flat and nice.
The nextcloud module have been updated to reflect this change as well
as the documentation.
I din't try to pinpoint the exact commit, but we started getting:
> The extension smart is not supported for docbook
Reading pandoc docs, I can't see what use to us "smart" could be
when writing the in-between docbook (to be converted to html).
https://pandoc.org/MANUAL.html#extension-smart
Previously, we would asssert that the lockfiles are consistent during the
unpackPhase, but if the pkg has a patch for the lockfile itself then we must
wait until the patchPhase is complete to check.
This also removes an implicity dependency on the src attribute coming from
`fetchzip` / `fetchFromGitHub`, which happens to name the source directory
"source". Now we glob for it, so different fetchers will work consistently.
This has several advantages:
1. It takes up less space on disk in-between builds in the nix store.
2. It uses less space in the binary cache for vendor derivation packages.
3. It uses less network traffic downloading from the binary cache.
4. It plays nicely with hashed mirrors like tarballs.nixos.org, which only
substitute --flat hashes on single files (not recursive directory hashes).
5. It's consistent with how simple `fetchurl` src derivations work.
6. It provides a stronger abstraction between input src-package and output
package, e.g., it's harder to accidentally depend on the src derivation at
runtime by referencing something like `${src}/etc/index.html`. Likewise, in
the store it's harder to get confused with something that is just there as a
build-time dependency vs. a runtime dependency, since the build-time
src dependencies are tarred up.
Disadvantages are:
1. It takes slightly longer to untar at the start of a build.
As currently implemented, this attaches the compacted vendor.tar.gz feature as a
rider on `verifyCargoDeps`, since both of them are relatively newly implemented
behavior that change the `cargoSha256`.
If this PR is accepted, I will push forward the remaining rust packages with a
series of treewide PRs to update the `cargoSha256`s.
No material changes to docs, but trying to sanitize them for consistent
readability prior to looking at #75837.
- Use `*` for lists instead of `-`. I have no opinion one way or the other, but
the latter was only used in 1-2 places.
- Pad the code blocks with whitespace.
- Wrap to 80 characters, except for a few 1-liners that were only slightly over.
When updating the section to python 3 some places still
referred to pythonPackages and were overlooked.
Decided to switch it to be more similar to the first
example binding pythonPackages and clarified comments a
bit based on confusion I observed on IRC.
Related to https://github.com/NixOS/nixpkgs/pull/77569
Updating section about imperative use of ad-hoc virtual-environments for
use of pythons built-in `venv` module via venvShellHook. Also trying to
make it a bit friendlier to beginners by adding a bit more explanation
to the code snippet and some remarks old-school virtualenv.
Adjusting for venvShellHook and adding manual example
Adding pip install and replacing python2 example with python3
