https://pantsbuild.org/ logo
#development
Title
# development
c

chilly-magazine-21545

10/13/2020, 3:37 AM
https://github.com/pantsbuild/pants/pull/10954 this allows try/except across an
await Get(...)
, which allows `@rule`s to raise exceptions without necessarily making pants exit immediately. i think this will be very useful for plugin authors, but it is easy to wait if we'd prefer to get 2.0 out the door first
f

fast-nail-55400

10/13/2020, 3:45 AM
there’s a release branch for 2.0.0 now so
master
changes shouldn’t need to wait
🚀 1
c

chilly-magazine-21545

10/13/2020, 3:45 AM
thanks!
h

hundreds-breakfast-49010

10/13/2020, 3:46 AM
exciting change, I'll definitely take a look at this soon
c

chilly-magazine-21545

10/13/2020, 3:46 AM
:D :D :D
no rush
was going through old PRs
h

hundreds-father-404

10/13/2020, 3:51 AM
This overall looks really exciting! Iirc, there was some discussion a while ago about the value of adding exception handling to rules because we generally want to discourage that style and encourage more FP-style of using the type system to express failure, like
Optional
. But also Python != Rust (e.g. no
Result
type), and it’s likely very valuable to have the mechanism, even if we discourage it.
🧠 1
c

chilly-magazine-21545

10/13/2020, 3:52 AM
yes that was my concern
h

hundreds-breakfast-49010

10/13/2020, 3:54 AM
yeah that's a fair point
but it's true that python doesn't really support FP-ish error handling, and python programmers expect to be able to use exceptions
👍 1
c

chilly-magazine-21545

10/13/2020, 3:55 AM
i was thinking this would be more familiar to python users and possibly improve the learning curve / make it easier to take advantage of 3rdparty python libraries that use exceptions when writing plugins. i think if python had rust enums i would not have proposed it, but as is, that pattern would require 3 separate dataclass definitions i think
👍 1
h

hundreds-father-404

10/13/2020, 3:56 AM
I haven’t had the time to look closely yet, so sorry if this is already answered, but one main question I have is if it’s possible to do exception handling for Rust failures. That might be really powerful to catch a failure for
MergeDigests
, for example. If anything, it would allow us to write much better error messages. (For example, it’s possible with the
output_path
field for the user to introduce conflicting paths from different assets. It would be AWESOME if we could
try except
that one
await Get
, and print a custom error message upon failure.) A big issue with error messages in the engine right now is that they have to be hyper generic, so they often miss valuable context
🚀 1
c

chilly-magazine-21545

10/13/2020, 3:56 AM
yes! that should work. i can write a test for it
1
h

hundreds-breakfast-49010

10/13/2020, 3:57 AM
I think if we can use this feature to implement better error messages today in pants, that justifies it
👖 2
c

chilly-magazine-21545

10/13/2020, 3:58 AM
i had totally missed how useful the intrinsic error handling could be
❤️ 1
h

hundreds-father-404

10/13/2020, 4:16 AM
It’d be excellent to add that as a major motivation in the PR description. And maybe proactively acknowledge the concerns about exception handling in general - we won’t liberally encourage the style, but there are a couple niche cases where it’s extremely valuable
👍 1
c

chilly-magazine-21545

10/13/2020, 4:16 AM
will do!
also it works to catch the
MergedDigest
error
❤️ 1
i have updated the description to reflect eric's message above
💯 2
h

hundreds-breakfast-49010

10/13/2020, 4:55 AM
btw I just created https://github.com/pantsbuild/pants/pull/10955, which has (I think) the last round I'm gonna do of converting python API functions to use
PyObject
instead of
Value
. not sure to what extent this is going to interfere with your code in this PR @chilly-magazine-21545
c

chilly-magazine-21545

10/13/2020, 4:59 AM
thank you for noting that! the only place we access attributes in the try/except PR is when extracting the exception traceback, which actually uses explicit hasattr/getattr. in fact i'd like your feedback on that whenever you get the chance to look at this because i'm not sure if i'm doing something wonky, i'll leave a comment in the section i'd like a look at
h

hundreds-breakfast-49010

10/13/2020, 5:00 AM
sure. I'm gonna sign off for tonight but I'll take another look at this tomorrow
c

chilly-magazine-21545

10/13/2020, 5:02 AM
thanks! i'll take a look at yours too
h

hundreds-breakfast-49010

10/14/2020, 6:18 AM
@chilly-magazine-21545 I left some comments on https://github.com/pantsbuild/pants/pull/10954, overall I think the approach is pretty solid, and most of my comments have been basically ways I noticed that the code in this PR could be more concise in any given spot
I realize https://github.com/pantsbuild/pants/pull/10954/files#r504425805 is kinda vague - basically, it seems like we're defining some pretty complicated types in python around
generator_send
and
generator_throw
, which to me suggests that we might be able to refactor
generator_send_or_throw_impl
into a few, simpler functions with simpler type inputs/outputs. but I can't immediately see a way to do this, so I might be wrong and this complexity is actually necessary