https://pantsbuild.org/ logo
Join Slack
Powered by
In order to solve <https://github.com/pantsbuild/p...
# development
c
In order to solve https://github.com/pantsbuild/pants/issues/15585 I’d like to optionally resolve 
UnparsedAddressInputs
. This has come up a few times before as well, where it would be desirable to not throw a 
ResolveError
for invalid/unknown addresses (as they may be something else, too) 🧵
I don’t think it is very difficult to solve, but are there any concerns you have how we go about this?
I’m considering adding a new bool field to 
UnparsedAddressInputs
that you can flip in order to get back `Address`es for all your inputs, but where addresses are gifted with a 
is_valid
boolean property that you can examine to see if it was indeed resolved properly or not.
f
I wrote some hacky code to optionally parse strings as addresses when dealing with Maven coordinates. It just catches any exceptions. See https://github.com/pantsbuild/pants/blob/9762509ed08c48e72af81bf0698e4667681acac5/src/python/pants/jvm/resolve/jvm_tool.py#L112-L116
c
Yeah, thats almost good, however in this case, the string may be formatted as a valid address (and I want it resolved if it indeed is an address too) into a 
Address
So I could catch the engine 
ExecutionError
I guess, but then it doesn’t interact well when I have a list of such addresses, some of which may throw..
Huh… so, looking at @hundreds-father-404’s Spec changes to implement ignores, I realise that maybe treating unparsed addresses as specs would actually work in this case, as there’s already implemented support for “unmatched glob behaviour” which I think will do what I want when set to “ignore”.
💯 1
h
Oh cool! Yeah, there is 🙂
🙌 1
Open in Slack
PreviousNext
Powered by