Some project may claim, in their README or otherwise, a particular library as
an optional dependency. But it doesn't make it one in the context of the
`optional-dependencies` derivation attribute.
Move the existing `yarnConfigHook`, `yarnBuildHook` and
`yarnInstallHook` documentation below a Yarn v1 section.
Also move the documentation for the deprecated `yarn2nix` there, which
is Yarn v1 only.
Co-Authored-By: Yureka <yureka@cyberchaos.dev>
They are not doing anything right now. This is in preparation for their
complete removal from the tree.
Note: several changes that affect the derivation inputs (e.g. removal of
references to stub paths in build instructions) were left out. They will
be cleaned up the next iteration and will require special care.
Note: this PR is a result of a mix of ugly regex (not AST) based
automation and some manual labor. For reference, the regex automation
part was hacked in: https://github.com/booxter/nix-clean-apple_sdk
Signed-off-by: Ihar Hrachyshka <ihar.hrachyshka@gmail.com>
This reverts commit 65a333600d.
This wasn't tested for correctness with something like fodwatch [0],
and should not have been (self-)merged so quickly, especially without
further review.
It also resulted in the breakage of at least one package [1] (and that's
the one we know of and was caught).
A few packages that were updated in between this commit and this revert
were not reverted back to using `rev`, but other than that, this is a
1:1 revert.
[0]: https://codeberg.org/raphaelr/fodwatch
[1]: https://github.com/NixOS/nixpkgs/pull/396904 / 758551e458
Cut down on the number of system images that need to be fetched by just
supporting packages from the last 5 years. Still test the last 10 years
of APIs without images.
When using `buildNodeModules` to create `node_modules` commands like `npm install` & `npm add` that writes packages & executables needs to be used with `--package-lock-only`.
It's confusing to have a polymorphic behavior for nvimSkipModule and it
is an implementation detail.
Let's not force ourselves to keep supporting both types and just support
lists, which imply plural in nixpkgs (e.g. "lib.optional" vs "lib.optionals").
Support and showcase just the list format to avoid confusion.
By replacing upstream's pg_config binary with a shell script, we:
- gain the ability to run pg_config easily when cross-compiling,
- can remove the fake pg_config in the default output,
- can remove the pg_config wrapper script dealing with special cases.
Some 20 years ago, pg_config *was* a shell script upstream, too. It was
changed to a binary, when it was made "relocatable", so it would return
paths depending on the location of the "postgres" binary. However, this
is exactly the thing that just hurts us in nixpkgs - we don't want those
paths to change, we want them to always point at the right outputs. By
writing the script ourselves, this becomes a lot less painful.
This approach means more lines of codes, but all of them are dead simple
and we have a lot less complexity overall.
Additionally, pg_config is now made a separate derivation, only exposed
as "postgresql.pg_config". This has the nice side-effect, that all users
of postgresql and libpq in nixpkgs must be very *explicit* about their
dependency on pg_config. This gives a lot more visibility into the state
of affairs regarding pkg-config support for libpq, which ultimately is
the much better solution.
testTarget takes a space separated list of test suites to run. We itnroduce a new testTargets argument that instead takes a list, and add a backwards compatibility shim
Cargo 1.84.0 broke fetchCargoTarball hashes, so fetchCargoTarball is
not long for this world. Tell people to use fetchCargoVendor, which
Nixpkgs is currently in the process of switching to across the tree.
