A --client session went without CLANG_PATH, CPATH and LIBRARY_PATH. The
guard is there because sbtn is absent on platforms upstream ships no
native client for.
Assisted-by: Claude Code (Claude Opus 5)
Renames the sha256 key to hash and converts the values, matching current
nixpkgs style.
The fetched artifacts are unchanged, so the store path stays the same.
Assisted-by: Claude Code (Claude Opus 5)
It shares a derivation name with plain sbt, which is one of the two
conventions in the tree, so the description is what tells them apart in
nix search and nix profile list.
Assisted-by: Claude Code (Claude Opus 5)
nixpkgs-update already bumps sbt from its own version detection, but sbt
keeps 1.x and 2.x alive at once and ships them on the same day -- v2.0.6
and v1.12.15 both landed 2026-08-07. Anything keyed on the most recently
published release can therefore propose a downgrade, so this picks the
highest version out of the tags instead and refuses to go backwards.
The X.Y.Z filter drops release candidates. sbt does flag those as
prereleases on GitHub, but tags carry no such marker and v2.1.0-RC1 would
otherwise sort above v2.0.6.
$UPDATE_NIX_ATTR_PATH is ignored because sbt-with-scala-native is
sbt.overrideAttrs and inherits this passthru, while its meta.position
points at its own file rather than the one holding the version.
Assisted-by: Claude Code (Claude Opus 5)
Asserts on the runner version the binary reports, rather than on its exit
status, and takes finalAttrs.finalPackage so an override is what gets
tested.
testers.testVersion is not used here because the runner needs a writable
HOME and --allow-empty to run outside a project.
Assisted-by: Claude Code (Claude Opus 5)
Nothing verified the built sbt runs. --version --allow-empty needs neither
a project nor the network, so the runner can be exercised in the sandbox.
Assisted-by: Claude Code (Claude Opus 5)
$out/bin held bare symlinks and nothing set PATH, so propagating ncurses
never got infocmp to a running sbt; it only pushed ncurses-dev into the
build environment of everything that depends on sbt. The native client is
what wants infocmp, so a wrapper is where it belongs.
Dropping the propagation does mean ncurses no longer reaches the
environment of anything that takes sbt as an input, `nix-shell -p sbt`
included.
Assisted-by: Claude Code (Claude Opus 5)
The if-chain fell through to the x86_64 client for every platform that was
neither darwin nor aarch64, so i686, armv7l, armv6l, powerpc64le and
riscv64 got a binary for the wrong architecture. Nothing failed:
autoPatchelfHook skips files whose architecture differs from the target,
so the build succeeded and shipped an sbtn that cannot run.
sbt itself is unaffected on those platforms, being a shell script and a
jar, so the client is simply left out where upstream has none.
Assisted-by: Claude Code (Claude Opus 5)
The LICENSE in the distribution is the Apache License 2.0, and GitHub
reports the repository as Apache-2.0. sbt was BSD-3 in its 0.x days.
Assisted-by: Claude Code (Claude Opus 5)
postPatch bakes -java-home into conf/sbtopts, so the jre this derivation
is given is the one every sbt invocation runs on, and sbt 2 exits with
"sbt 2.x requires JDK 17 or above" on anything older. Asserting turns that
into an evaluation error, as scala-cli already does.
Assisted-by: Claude Code (Claude Opus 5)
What is packaged here is the runner, not the build tool a project uses:
each project declares its own version in project/build.properties, which
the 2.x runner reads and honours, so existing 1.x builds keep working.
Verified against a project pinned to 1.12.15, where `sbt --version`
reports the runner as 2.0.6 and the project as 1.12.15.
A directory with no project/build.properties now falls back to 2.0.6.
Supersedes https://github.com/NixOS/nixpkgs/pull/537442.
Assisted-by: Claude Code (Claude Opus 5)
The daemon mill starts is Java 17 bytecode. Upstream saying it "supports
every JVM version from 11 onward" is about the JVMs a build may target,
not the one mill itself runs on.
Assisted-by: Claude Code (Claude Opus 5)
Only PRs to packages in pkgs/by-name can be merged with the merge bot, so
this is what lets the package's maintainers act on r-ryantm's bumps.
Both callPackage calls took empty argument sets, so no .override interface
changes. simpleBuildTool stays in all-packages.nix, being an alias rather
than a definition.
Assisted-by: Claude Code (Claude Opus 5)
--set-default left an ambient JAVA_HOME in charge, so overriding jre had
no effect on the daemon mill starts. Also switches to jre.home, which is
the attribute meant for this, and to lib.makeBinPath for the PATH entry.
Assisted-by: Claude Code (Claude Opus 5)
It called nix-prefetch-url and `nix hash convert` without nix on its
pinned PATH, so it only worked through the ambient PATH it appended.
It also rewrote package.nix once per platform with no way back, so a
failure on the second or third left the file half updated. It now restores
the file unless the whole run succeeds, refuses to downgrade, passes
--fail to curl, honours $UPDATE_NIX_ATTR_PATH and supports the `commit`
updateScript feature. writeShellApplication runs shellcheck over it at
build time.
Assisted-by: Claude Code (Claude Opus 5)
The artifact suffix, the hash and meta.platforms were three lists of the
same three systems that had to agree by hand; the update script iterated
meta.platforms and threw if a system was missing from the suffix table.
They are now one table, with meta.platforms derived from it.
The legacy sha256 attribute held SRI values, so it becomes hash.
Assisted-by: Claude Code (Claude Opus 5)
It was spelled preferLocal, which Nix does not recognise, so it reached
the derivation as an inert environment variable and the comment above it
never took effect.
Assisted-by: Claude Code (Claude Opus 5)
meta.platforms was absent rather than wrong, and check-meta only applies
the platform check when the attribute exists, so metals was offered on
every system including those with no jre.
coursier fetches prebuilt jars, so sourceProvenance is binaryBytecode.
Assisted-by: Claude Code (Claude Opus 5)
installPhase called neither runHook preInstall nor runHook postInstall,
so overrideAttrs (_: { postInstall = ...; }) was silently dropped.
Assisted-by: Claude Code (Claude Opus 5)
Both were top-level mkDerivation attributes, so they reached the builder
as environment variables. extraJavaOpts becomes a package argument, the
way josm takes its own, and deps moves under passthru, which is also what
makes it reachable for an updater the way dotnet fetch-deps and
fetchedMavenDeps are.
Both keep their names and defaults, so the build is unchanged and the
flags stay tunable -- through
`metals.override { extraJavaOpts = "-Xmx4g"; }` now rather than
.overrideAttrs.
Assisted-by: Claude Code (Claude Opus 5)
bintray shut down in 2021, and sonatype:snapshots has no business
resolving a release artifact. Neither contributes anything: fetching the
dependencies with them removed produces the same hash, so the store path
does not move.
Assisted-by: Claude Code (Claude Opus 5)
It put the jre on PATH but left JAVA_HOME alone, so anything consulting
that rather than PATH got nothing - and `cs java` will go and fetch a jdk
of its own when JAVA_HOME is unset.
Assisted-by: Claude Code (Claude Opus 5)
The tag glob v*.*.* also matches milestones, so the script would have
bumped this to v2.1.25-M26; it now keeps only plain X.Y.Z tags.
It also carried two dead lines, one of them naming a path that stopped
existing when the package moved to pkgs/by-name. The rest is the shape the
other Scala packages now use: shellcheck at build time, a downgrade guard,
$UPDATE_NIX_ATTR_PATH, prose on stderr, and package.nix restored if
update-source-version fails partway.
--print-changes was already emitting the commit JSON, but the bare-script
form of passthru.updateScript declares no supportedFeatures, so nothing
ever asked for it.
Assisted-by: Claude Code (Claude Opus 5)
The launcher ships prebuilt coursier/bootstrap/launcher classes, so
sourceProvenance is binaryBytecode rather than the fromSource default.
Assisted-by: Claude Code (Claude Opus 5)
lib.platforms.all claimed 79 systems, x86_64-windows among them, for a
wrapped shell script that needs a jre and sets LD_LIBRARY_PATH.
Deriving it means scala-runners, which overrides the jre with jdk8, gets
the four systems jdk8 supports rather than inheriting a list asserted
independently of the jre in use.
Assisted-by: Claude Code (Claude Opus 5)
All three variants build a derivation called ammonite-3.0.9, so the
description is what tells them apart in nix search and nix profile list.
Assisted-by: Claude Code (Claude Opus 5)
Checks the wrapper and the autopatchelfed binary answer --help, which is
the only thing that works without network access: everything that reaches
the build server downloads it from Maven Central first.
Assisted-by: Claude Code (Claude Opus 5)
ammonite.AmmoniteMain is class-file 55, so an older jre failed the install
check with UnsupportedClassVersionError buried in a build log rather than
saying why.
Assisted-by: Claude Code (Claude Opus 5)
