https://pantsbuild.org/ logo
Join Slack
Powered by
<@U0N6C2Q9F>: any thoughts on <https://github.com/...
# development
w
catching up on other things, then will start that
f
Also, while it’s been useful to have more data emitted as JSON to Python, it occurs to me that we could be doing ~all of the consumed symbols calculations inline in the parser (or at least, before emitting JSON).
that gets into partial type solving which is something that I had looked into a little but punted on as JavaParser’s existing code wants to completely type solve and it would’ve required a fair bit of work to try and do partial type solving
w
yea
f
and I didn’t try for Scala since those rules are more complex
but if you are able to do some heuristic partial type solving, then all the better
w
also, after writing that comment, i remembered that one of the reasons we wanted to wait was that we thought that we might want to expose more options to control the behavior, without pushing them to the extractor
f
just a question of cost vs benefit
but definitely a path that was “on the radar” in development
and I never got the chance to see what scalameta had for type solving
responded with a summary on the ticket
w
thanks.
i’m going to cleanup/unify the BUILD files for the java/scala parsers (but not their hardcoded requirements)
will that conflict with work on https://github.com/pantsbuild/pants/issues/13754 ?
i’ll get it out soon, regardless, in hopes that you’re not very far along 😃
…hm, crap. this is overlapping more than i thought.
…actually, i see a good breaking point, pheew.
f
It won’t conflict since I’m not going to port everything to it at once.
👍 1
I’ll pick one thing to port to it, then the rest can be follow-up PRs.
w
the parallel with Python tool lockfiles is interesting. but one weakness of the Python tool lockfiles is that you can’t define them using a target
(not necessary in a first version, regardless)
f
it also overlaps with selecting SDKs (e.g., the Go SDK and the terraform tool), having a consistent way to do that as a target type would be nice
since we could express the dependencies explicitly in the build graph
w
yea.
a bit of a stretch goal, since i think the priority for this milestone is more around removing redundancy before adding more tools? but if it falls out naturally, then let’s do it
f
I’d like that eventually but not now
not sure what form it would take. my plan was to experiment with various ideas with the terraform backend.
then we can see what form actually works
for now, just duplicating the Python generate-lockfiles design with a parallel JVM version. then we can decide how to merge if at all after I have it out.
Open in Slack
PreviousNext
Powered by