https://pantsbuild.org/ logo
Join Slack
Powered by
Getting-BSP-running thread
# development
a
Getting-BSP-running thread
Currently importing into intelliJ gives me this error:
Copy code
request failed: buildTarget/scalacOptions
bsp error: ValueError: File with digest Digest { hash: Fingerprint<08f983b45ef2306eaca35e9280aae2b8691a063e1f2d04b0f5d38f910cda7c19>, size_bytes: 134857 } not found (-32602)
that hash corresponds to 
com.google.errorprone:error_prone_annotations:2.7.1
It starts working if you run 
./pants check ::
before doing a BSP import though. Is this intended behaviour, or do we want a BSP import to work cleanly before running pants? (@witty-crayon-22786 @fast-nail-55400)
w
mm, no: that’s a bug that i noticed and then forgot about. the code is currently directly taking digests from the lockfile and assuming they already exist on disk
i’ll file it.
a
clearly 🙂
thanks!
w
a
@witty-crayon-22786 I’m reaching a bit of an impasse here — I can definitely get IntelliJ to pick up a hardcoded JDK path. The problem is that creating that JDK path requires us running 
cs java-home
under a sandbox, which appears to put everything under hardlinks. I could potentially use the “runtime JDK” stuff that I put in place for running deploy JARs, and materialise the JDK into 
.pants.d/bsp
, but that still seems a bit icky. Thoughts?
(happy to jump on a call to talk it through, too… this probably needs more pickling of internals than I expected)
w
which appears to put everything under hardlinks
that should be fine…? it should be a location under 
~/.cache/pants/named_caches
a
Yes, that’s correct
the trick is that the suffix is loooooooooooong
w
such that it causes a failure?
a
No failures yet, it’s more about trying to actually get a directory name that I can give to intelliJ and expect it to stick around
w
imo, inside of the cache is fine.
a
I know that
the problem is actually finding the directory in the cache
w
is the issue that 
cs java-home
is giving you the location within the sandbox? to resolve that, you’d need to use the bash equivalent of 
realpath
to have it resolve through the symlink
a
I definitely expect the jdk to stick around, the issue that coursier unpacks it unto a directory that is hardlinked inside the sandbox
w
symlinked*
a
mac os seems to think it’s a hardlink, can I dereference that?
w
a parent directory is a symlink
inside of the sandbox there will be a 
.cache/coursier
directory, and that will be the symlink
but i think that a canonical path / realpath call on the full path will still expand that
a
Copy code
chrisjrn@chrisjrns-MacBook-Pro ~ % readlink /private/var/folders/0m/h2n902qn38b8555xq8z0w_h40000gn/T/immutable_inputstJXCO1/fbecc478ab0e4f4ccfcd16d6505d2d0c5ea494e2e0a1a1ce5bba5f216597fbbd
chrisjrn@chrisjrns-MacBook-Pro ~ % echo $?
1
w
the JDK isn’t an immutable input
it’s in the named caches
a
One moment
w
a
I am working from that, one moment
w
something like 
realpath $(cs java-home)
should do it
a
OK, I can run 
realpath
from the jdk preparation script, and that gives me the cache (I’d been using readlink, which I think needs you to find the specific directory rather than going up the tree itself)
w
yea
that’s right about readlink.
a
realpath looks like it comes from homebrew, so I think I’ll have to traverse that tree myself
(sigh)
w
hm
oh. hm. yea, that’s annoying.
a
Actually, I should be able to do that in python just by finding the common suffix
w
um. maybe do it from Python?
oh. crap…. not quite.. the sandbox will already be cleaned up.
but: if you write the script as a python script using 
PythonBinary
, you can run python in the sandbox
a
right
what we do with literally everything else in JVM land 🙄 😄
Hoooray!
w
lol
a
it actually works!
w
nice! … just laughing at the path length
a
Yeah. Well, can’t win them all 😄
w
#shipit
a
Let me rename the variables from 
scripty_friend
and other such nonsense first
EXPLORATORY CODING, STU
@witty-crayon-22786 https://github.com/pantsbuild/pants/pull/15408 Thanks, I hate it 🙂
Open in Slack
PreviousNext
Powered by