New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Bloop: 1.3.4 -> 1.4.3 #91758
Bloop: 1.3.4 -> 1.4.3 #91758
Conversation
@karolchmist & @svalaskevicius please take a look. The problem of non-fixed hash should be fixed. Sorry to multiply the PRs, but it just seemed much easier to just throw my modifications into a new branch and fiddle with git than trying to update the other PR. |
Hello @Tomahna, nice! I just tested it, works great. I have no power of merging, but it's 👍 from me. |
Looks good to me too :) thanks! Not too sure what's the process of actually merging it, last few times @worldofpeace helped. |
Reviewed points
Possible improvementsComments |
Updated with bloop 1.4.3 |
* Include all completions * Update derivation to make it similar to archlinux packaging
What test can I do to determine this upgrade has been successful? |
You can use Other than that, well you would have to set up a basic scala environment and build a scala project with it. |
On Darwin and with bloop 1.4.3 from your latest update,
If I install bloop using coursier, |
It is strange, it starts the server properly on nixos.
Can you try starting the build server manually (through the My guess is that the installer does not select the correct binary. |
|
Hi @ludovicc, I've adapted the derivation to be able to fetch correct binaries on darwin. Unfortunately I do not have a mac to test it. Could you give it a try ? You would have to provide the correct sha256 for darwin (line 56). I've not been able to figure out how nixos computes the recursive sha256 yet. (Or to find out how to test it for another platform). |
@Tomahna here are the logs of a build on Darwin:
If you use 06c885w088yvh8l1r1jbrz0549gx2xvc8xr6rlxy6y27jk5655p2 as sha256 code for the darwin binary, it works well:
|
Awesome, I've updated this PR with the provided sha. |
I re-tested on Darwin (macOs Catalina 10.15.5), it works well. |
does anyone know what's left to be done before this can be merged? :) |
@jonringer can you review this pr? LGTM on my side. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
seems to only work if java on PATH:
[nix-shell:/home/jon/.cache/nixpkgs-review/pr-91758]$ nix-shell --pure -p "with import ./nixpkgs {}; bloop"
these derivations will be built:
/nix/store/cl19rgxmxni5c2y1aw8bjnwq3ick49b9-bloop-1.4.3.drv
...
[nix-shell:/home/jon/.cache/nixpkgs-review/pr-91758]$ bloop --help
No server running at 127.0.0.1:8212, let's fire one...
Resolving ch.epfl.scala:bloop-frontend_2.12:1.4.3...
Starting bloop server at 127.0.0.1:8212...
java.io.IOException: Cannot run program "java" (in directory "/home/jon/.cache/nixpkgs-review/pr-91758"
....
[nix-shell:/home/jon/.cache/nixpkgs-review/pr-91758]$ nix-shell --pure -p "with import ./nixpkgs {}; [ bloop openjdk.jre ]"
[nix-shell:/home/jon/.cache/nixpkgs-review/pr-91758]$ bloop about
No server running at 127.0.0.1:8212, let's fire one...
Resolving ch.epfl.scala:bloop-frontend_2.12:1.4.3...
Starting bloop server at 127.0.0.1:8212...
Attempting a connection to the server...
Attempting a connection to the server...
Attempting a connection to the server...
bloop v1.4.3
Using Scala v2.12.8 and Zinc v1.3.0-M4+45-d4354be3
Running on Java JRE v1.8.0_242 (/nix/store/7qknskbanpwq7a71s2n6dv3l5b3frj7d-openjdk-8u242-b08-jre/lib/openjdk/jre)
-> Doesn't support debugging user code, runtime doesn't implement Java Debug Interface (JDI).
Maintained by the Scala Center (Jorge Vicente Cantero, Martin Duhem)
I'm not sure what to do about that. The precompiled binary is expecting Java on the classpath, I don't see how we can patch that. Should the derivation do something about it ? Is it really a problem ? |
wrapping doesn't seem to work, but doing |
|
||
nativeBuildInputs = [ autoPatchelfHook ] ; | ||
phases = [ "installPhase" "fixupPhase" ]; | ||
buildInputs = [ stdenv.cc.cc.lib zlib ] ; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
fix java missing issue
buildInputs = [ stdenv.cc.cc.lib zlib ] ; | |
buildInputs = [ stdenv.cc.cc.lib zlib ] ; | |
propagatedBuildInputs = [ openjdk.jre ]; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
this does increase the closure size quite a bit:
[nix-shell:/home/jon/.cache/nixpkgs-review/pr-91758-4]$ nix path-info -Sh ./results/bloop
/nix/store/fp1kc7lxw0rhhs6my624wm154hn8494w-bloop-1.4.3 77.2M
[nix-shell:/home/jon/.cache/nixpkgs-review/pr-91758-4]$ nix path-info -Sh ./result
/nix/store/c0ls7dh4vnjd4wyqib3mz6yyfz2n3g49-bloop-1.4.3 434.8M
However, it's more representative of it's actual runtime closure:
[16:52:28] jon@jon-desktop /home/jon/projects/nixpkgs (buildDotnetCorePackage)
$ nix path-info -Sh ./result-jre
/nix/store/7qknskbanpwq7a71s2n6dv3l5b3frj7d-openjdk-8u242-b08-jre 396.5M
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This does still mean that we can change to any java we want when using bloop, right? :)
In fact, why are we adding java 8? Does the build not work without it or usage?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks like a similar thing is done for sbt already - https://github.com/NixOS/nixpkgs/blob/master/pkgs/development/tools/build-managers/sbt/default.nix, and we can override jvm for bloop processes, so yeah (answering my own question) :)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Would be good if there was a way to configure preferred java provider (or at least the major version) in one place though, but thats much more generic question than this PR
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
as with most things with nix, there's a way to do anything, it's just how much pain is it to introduce flexibility. I guess you could pass jre
to this derivation, and then just say:
bloop = callPackage ../.. {
jre = openjdkXX.jre;
};
and then if you want to change it, then you would do something like:
bloop.override { jre = blah.jre; };
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It does not seem necessary to explicitly pass the jre in the callPackage call, several other derivations which use jre do not do it (coursier, scalafmt, metals, ...).
However by passing the jre inside the derivation, it seems to respect the programs.java.package property or can be overriden with derivation.override.
}; | ||
|
||
nativeBuildInputs = [ autoPatchelfHook ] ; | ||
phases = [ "installPhase" "fixupPhase" ]; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
manually defining phases is deprecated. See the stdenv chapter of the nixpkgs manual to disable phases like dontBuild = true;
etc.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It's replaced by dontUnpack = true.
else throw "unsupported platform"; | ||
}; | ||
|
||
nativeBuildInputs = [ autoPatchelfHook ] ; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
nativeBuildInputs = [ autoPatchelfHook ] ; | |
nativeBuildInputs = [ autoPatchelfHook ]; |
this is done in various places
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Should be fixed
All your review comments should have been taken into account and fixed. |
@worldofpeace @jonringer hi, please can you review if you're happy with the changes? Would be good to get this merged as the old bloop version is not really usable anymore (not compatible with the new scala version etc) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
sorry, went on vacation for a week and a half |
thanks! also thanks to everyone involved, especially @Tomahna - for continuously maintaining this derivation - over a few bloop releases now :) |
Motivation for this change
Updates bloop from 1.3.4 to 1.4.2.
During the 1.4.+ upgrade, bloop has changed the way it is packaged. While the previous way of packaging it still works, bloop now uses graalvm native images in other distributions. This PR updates the derivation in order to be as close as possible to the way bloop is packaged in the archlinux user repository
This PR should supersedes #89359, commits and attributions have been kept.
Things done
sandbox
innix.conf
on non-NixOS linux)nix-shell -p nixpkgs-review --run "nixpkgs-review wip"
./result/bin/
)nix path-info -S
before and after)