Would y'all be open to a PR to expand `Resolver.ge...
# ksp
z
Would y'all be open to a PR to expand
Resolver.getDeclarationsFromPackage()
to allow including subpackages too? We have a good use case for this in Anvil
j
What do you mean by subpackage?
z
Give
com.example
, I want to also fetch
com.example.subpackage
But I only know about the first one at processing-time
This is possible with the underlying module itself, just would like to avoid using a private API to achieve the same result :)
j
I see, that looks doable from implementation side, caveat is that this API have the potential of extracting the whole classpath out though.
alternatively, what if we just provide an API to give you a list of subpackages under a pacakge name? So that you can subsequently use the package names to get the declarations using existing API?
z
yeah that would work too 👍
👍 1
we want from dependencies too, not just sources. In case it matters
j
That should be fine, we already return symbols from dependencies for getting from package.
z
awesome. Should I file an issue summarizing this?
or just go straight for the PR?
j
Sounds good, please go ahead with an issue to begin with.
👍 1
z
do you want me to try a PR?
j
That should also work if it fits your bandwidth 🙂
z
Will do
thank you color 1
Does the ResolverAAImpl do the inverse of this by coincidence? The code appears to gather all the symbols of parent packages as well as the requested package
j
it was intentional, the reason for the code is that you might get multiple package symbols for same package name therefore you need to visit all package symbols and filter by name and union them.
z
interesting, and not necessary in KSP1's impl?
j
yes, they are different
👍 1
z
initial impl here: https://github.com/google/ksp/pull/1796. Working on tests next
👍 1