forking off from the `fmt` / `fix` thread: we obvi...
# development
w
forking off from the
fmt
/
fix
thread: we obviously haven’t been focused on plugin stability recently, but we have been adding items to https://github.com/pantsbuild/pants/projects/19 as a grab bag of things that we might want to resolve before stabilization.
some of them are very much “wish list” items rather than actual necessities. but there are some issues that definitely qualify as blockers in my mind: https://github.com/pantsbuild/pants/issues/12934 in particular, since `@union`s are too limited right now.
and, having finished reading through that thread, i think that i was assuming it was more about the plugin API than it actually is: user API deprecations are another story
i’ve aded an example to #12934, which might spark some ideas for API changes:
Copy code
class Field:
    @rule_helper
    @staticmethod
    async def compute_default_value() -> Any:
        ...

class JvmResolveField:
    @rule_helper
    @staticmethod
    async def compute_default_value() -> Any:
        jvm = await Get(JvmSubsystem, ..)
        return jvm.default_resolve
…it could allow for pretty significant improvements to plugin APIs.
b
Finally someone using
rule_helper
on a method 😈
Don't forget though the `Get`s are collected using static type lookup though
w
yea, see the other (recent) comments on that ticket. this would require some sort of syntax at callsites to connect the list of
@union
members
b
I semi-dream of a world where any field is defaultable with options. Really completes the story for fields/options/`__defaults__` IMO. This would get us closer 🙂
I don't completely grok the issue link, but I'm sure I will when it comes closer to fruition