https://pantsbuild.org/ logo
Join Slack
Powered by
<@U06A03HV1> JVM user lockfile question in-thread:
# development
a
@witty-crayon-22786 JVM user lockfile question in-thread:
Having spent some time poking around the JVM lockfile resolution code, for user lockfiles — at the moment, I’m validating that a lockfile’s metadata requirements (the requirements at generate time) exactly matches the requirements for the given lockfile resolution request. That will need to change so that the request requirements are a subset of the metadata requirements, given that we only ever look for the requirements that satisfy specific dependencies. At the moment, it looks like we resolve the lockfile for each individual dependency (and rely on cache behaviour to make this non-slow). This means that we can only look at a single requirement when verifying if a lockfile is incorrect. We can verify that the requirement matches the metadata this way, so invalidation behaviour will be correct. It just means that the error when we experience an invalid lockfile will only be able to refer to the first broken requirement. The solution -- which the error message would suggest -- is to run 
generate-lockfiles
, which should resolve all of the further errors. The alternate solution is for 
ClasspathEntry
to include the lockfile objects and the input requirements used to generate the 
ClasspathEntryRequest
, and merge those. This seems like a lot of extra work for an error message. I’d like to know what you think here.
w
At the moment, it looks like we resolve the lockfile for each individual dependency (and rely on cache behaviour to make this non-slow).
somewhat… we compute the resolve to use at the top of any given run (before kicking off compilation)… so the “resolution” that happens should be a lookup from the name to its location on disk. but yea, that part is memoized.
It just means that the error when we experience an invalid lockfile will only be able to refer to the first broken requirement.
this seems fine to me, and like the implementation that is most likely to be performant
a
Cool.
w
h
Given how much Chris and I are touching the same code, would it make sense for you Chris to first merge 
generate-lockfiles
and 
coursier-resolve
goals? I have not started that yet, only added functionality to 
generate-lockfiles
to do it Not clear to me if they're orthogonal enough
a
fancy!
w
…when a requirement does not exist in the lockfile. so this would be closer to “this precise requirement, including its version, is not in the lockfile”
👍 1
a
@hundreds-father-404 Let me get back to you shortly
👍 1
@hundreds-father-404 If you can point me in the correct direction, I might be able to do that next, but not in this PR. If not, it’s just a matter of ensuring that the metadata is added, per https://github.com/pantsbuild/pants/pull/14185/files#diff-929c30b73589e6371a8e89e8d652bcb4bfdd5efabcc755f6bb445ece254b7ed3R109
h
Okay sg, I'll try knocking it out rn. I just wrapped up my other tasks for the day
Open in Slack
PreviousNext
Powered by