Package Maven 4 as a standalone derivation that can be customized
independently of maven.
It defaults to jdk25_headless (the JDK can be overridden via that
argument), exposed through a local jdk_headless binding so future JDK
bumps are a one-line change.
maven exposes its package builder as the mkBuildMavenPackage passthru
function, which maven_4 reuses to provide its own buildMavenPackage
without duplicating build-maven-package.nix. The version tests passthru
is exposed as well. buildMaven is intentionally not exposed as it is
semi-deprecated.
The dependency FOD deletes the .meta directory during cleanup: Maven
Resolver 2.0.11+ writes machine- and time-dependent files there, which
would otherwise break the fixed-output derivation's hash.
A section about maven_4 is added to the Maven manual.
Assisted-by: Claude Code (Claude Opus 4.8)
fetcherVersion = 1 and 2 were deprecated in the 26.05 release and
scheduled for removal in 26.11. Remove them from supportedFetcherVersions
and replace the deprecation warning with a hard throw that points users
at the migration to fetcherVersion = 3.
No in-tree package still uses fetcherVersion = 1 or 2. The now-unreachable
v1/v2 code paths are removed in a follow-up commit.
Assisted-by: claude-code with claude-opus-4-7[1m]-xhigh
Remove python27Packages, python2Packages, and pythonPackages alias
mentions; drop the "python refers to CPython 2.7" sentence and the
Python 2 namespace-collision note; strip Python-2-only inline comments
from the venvShellHook example.
Keep all pypy2/pypy27 references — pypy27 stays defined inside
pythonInterpreters as the bootstrap for pypy3.
Document a method to override package or collection dependencies with texlive.withPackages
Co-authored-by: Vincenzo Mantova <1962985+xworld21@users.noreply.github.com>
The pnpm v11 store uses a SQLite database (index.db) whose binary format
is non-deterministic across platforms (version-valid-for number, etc).
This caused hash mismatches when building the same pnpmDeps on different
machines despite identical logical content.
Fix by dumping the SQLite database to a text SQL file during the fetch
phase and reconstructing it during the build phase. This ensures the
stored representation is fully deterministic.
Assisted-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
Co-authored-by: Gergő Gutyina <gutyina.gergo.2@gmail.com>
buildRustCrate calls rustc directly, so there is no built-in equivalent
of `cargo clippy`. The capLints doc already hints at the existing
workaround — overriding the `rust` attribute with a wrapper script that
sniffs argv for build_script_build and routes everything else to
clippy-driver. That works because clippy-driver IS rustc internally
(rustc_driver plus lint passes) and produces compatible rlibs and
metadata, but the wrapper is fragile and every downstream reinvents it.
Add a `useClippy` boolean (default false) that swaps the lib/bin/test
compilation to clippy-driver while keeping plain rustc for build.rs —
the same lib-vs-build-script split as extraRustcOptsForBuildRs, since
build scripts are typically auto-generated and clippy noise there is
not actionable. The clippy-driver binary comes from a new `clippy`
parameter, auto-filled from pkgs.clippy by callPackage and overridable
alongside `rust` for toolchain bundles that ship their own.
Implemented by introducing a RUSTC_DRIVER shell variable in
build-crate.nix that lib.sh's build_lib/build_bin consume; the
build_script_build path in configure-crate.nix never sees it.
Note that the default `capLints = "allow"` cap suppresses clippy lints
along with everything else, so `useClippy` is usually paired with
`capLints = "warn"` and `-W clippy::*`/`-D warnings` flags via
extraRustcOpts. Documented in the manual.
Test fixtures cover the three load-bearing properties: a denied clippy
lint fails the build (proving clippy-driver ran), the default capLints
silences clippy lints just like rustc lints, and an rlib emitted by
clippy-driver is link-compatible with a plain-rustc dependent.
Proc-macro crates are host dylibs that rustc dlopen()s. Instrumentation
flags passed via extraRustcOpts (e.g. -Zsanitizer=address,
-Cinstrument-coverage) leave unresolved runtime symbols in those dylibs
and break the build. Cargo avoids this by not applying RUSTFLAGS to host
artifacts; buildRustCrate already has extraRustcOptsForBuildRs for build
scripts, so add the analogous knob for proc-macros.
Defaults to null, which falls back to extraRustcOpts so existing callers
are unchanged. Set to [] to opt proc-macros out when applying
sanitizer/coverage flags tree-wide via crateOverrides.
Extend the existing v1 deprecation warning to also fire for
`fetcherVersion = 2`, since callers should migrate directly to
`fetcherVersion = 3`. Both pre-v3 versions now share a single
`lib.warnIf` keyed on `fetcherVersion < 3` and produce a message
parameterised by the offending version.
Consolidate the manual's version-history entries: the per-item
**Deprecated** and **Recommended** labels are replaced by a single
sentence above the list noting that v3 is recommended and v1/v2 are
scheduled for removal.
Add a release note mirroring the existing v1 entry.
This allows calling `buildMavenPackage` with a function that receives a
`finalAttrs` parameter, much like `stdenv.mkDerivation(finalAttrs: ...)`
works.
fetcherVersion = 1 was kept around for backwards compatibility while
callers migrated to 2/3.
Emit a `lib.warnIf` warning pointing at the affected pname whenever v1
is used.
After 26.11 ships, a follow-up PR should drop 1 from
`supportedFetcherVersions` and clean up the dead v1 code paths in
default.nix, pnpm-config-hook.sh and serve.nix.
Also rewrite the manual section to recommend fetcherVersion = 3 for new
packages and mark v1 as deprecated/scheduled-for-removal in the
version history.
Signed-off-by: Sefa Eyeoglu <contact@scrumplex.net>
