The version and the per-platform asset names and hashes become data,
replacing the two if/else chains that selected them. A following commit
adds an update script, which can then rewrite JSON instead of Nix.
meta.platforms is derived from the asset list, so the two cannot drift,
and meta.changelog can be built from the same data.
The fetchurl calls move from derivation attributes into let bindings; they
were only ever used through string interpolation in installPhase, so being
attributes just put their store paths in the build environment.
Assisted-by: Claude Code (Claude Opus 5)
meta.platforms has never listed x86_64-darwin, so the branch selecting
this asset was unreachable and its hash was never checked against
anything.
Assisted-by: Claude Code (Claude Opus 5)
Upstream replaced the fish-completions asset of every release at some
point, but the hash here has not changed since 1.5.11. A fetchurl whose
hash still matches resolves out of the binary cache no matter what the URL
now serves, so nothing ever failed and users kept getting the 2023
completions.
Assisted-by: Claude Code (Claude Opus 5)
The repl pinned its own jvm but handed subprocesses whatever the shell
had. makeWrapper is not usable here because the launcher passes itself as
the classpath with -cp "$0", so the exports go ahead of the exec instead,
and the result is checked rather than assumed.
Assisted-by: Claude Code (Claude Opus 5)
The sed behind it looks for ammonite.Main', but the 3.x launcher runs
ammonite.AmmoniteMain, so it has matched nothing for some time and the
flag was never added: the default build contains no --no-remote-logging.
Upstream removed the feature as well, and answers the flag with "Option
--no-remote-logging is deprecated (remote logging has been removed)".
So the argument only ever chose between two identical launchers, except
that passing it false also skipped the shebang.
The built output is unchanged. This does drop the argument from the
.override interface, so `ammonite.override { disableRemoteLogging = false; }`
now fails to evaluate rather than quietly doing nothing; nothing in the
tree passes it.
Assisted-by: Claude Code (Claude Opus 5)
Upstream ships a .bat/.sh polyglot with no interpreter directive, and the
sed adding one sat inside the disableRemoteLogging block, so building with
that argument false produced a launcher execve cannot start: shells retry
it under /bin/sh, but anything calling execve directly gets ENOEXEC.
The default build is byte-identical; only the --no-remote-logging flag
stays conditional.
Assisted-by: Claude Code (Claude Opus 5)
The launcher carries an appended jar, so sourceProvenance is
binaryBytecode rather than the fromSource default.
Assisted-by: Claude Code (Claude Opus 5)
It refreshed ammonite_2_12 and ammonite_2_13 only, so a bump left
ammonite_3_3 - which is what the plain ammonite attribute points at - on
the new version with its old hash. The variants are now one table the
script is generated from, so none can be missed.
It also drove git ls-remote off git@github.com:..., which needs an ssh key
and so could never have run for r-ryantm.
The rest is the shape the other Scala packages use: shellcheck at build
time, a downgrade guard, prose on stderr, package.nix restored if a
refresh fails partway, and the commit feature declared.
Assisted-by: Claude Code (Claude Opus 5)
The launcher picks $JAVA_HOME over its own default when set, and only the
default was being patched, so `override { jre = ... }` had no effect in any
shell that exports JAVA_HOME - which is most of them. Ammonite 3 needs
Java 11, so on an older JAVA_HOME it crashed in the launcher instead.
sed rather than substituteInPlace because the launcher carries an appended
jar, and null bytes make substituteInPlace refuse the file. Since sed is
silent when it matches nothing, which is how this went unnoticed, the
result is checked.
Assisted-by: Claude Code (Claude Opus 5)
