https://pantsbuild.org/ logo
Join Slack
Powered by
Folks, I'll be spinning up the Pants weekly dev re...
# announce
e
Folks, I'll be spinning up the Pants weekly dev release in the next hour unless I hear of someone that wants me to hold.
h
Could you please merge https://github.com/pantsbuild/pants/pull/9723 if it doesn’t need any changes? I’m away for the rest of the night
e
LGTM so will do on green.
❤️ 1
That's in.
❤️ 1
h
Oh, could I also please get a ship it for https://github.com/pantsbuild/pants/pull/9708? I want to add a “Project introspection” page to the docs and we need this to land first.
e
Looking...
LGTM, I'll get that in the release on green.
h
Thank you! For opting out, Benjy recommended allowing it so that it’s consistent with all other backends. Meanwhile, core/ can’t be opted out of it because deregistering goals like 
fmt
would break most backends like the python backend
e
I just don't see why we'd want to allow opting out of goals needed for all other goals.
h
These aren’t needed for the other goals. You can meaningfully deactivate 
list
without breaking Pants. You can’t do that with 
test
e
Threy are for a user
If you have any targets at all you need list and target types, etc.
It just makes no sense to deactivate afaict even if its consistent.
h
Well, depends how pedantic we are in defining 
needs
. It still works without those goals. But I agree it’s not very useful for an end user to deregister 
target-types
or 
filedeps
e
Yeah - I think deactivation tends towards the pedantic. It makes sense to always have these in our prelude.
h
I’m fine with always activating them, I think I prefer that. Cc @happy-kitchen-89482 though, who advocated the consistency of being able to deactivate. For this PR, do you think we still keep it in pants.backend? But change the init code to always activate them? (Ik we have the bigger change to backends planned)
e
Think of it from a support perspective. To not be able to reliably ask a user to list is - needless petard foisting.
💯 1
As said in this PR I think the PR is fine for other reasons.
I just thought that justification was bogus.
h
Agreed. And it is easy to accidentally deregister them. If you use backend_packages2 = [] instead of .add = [], you’ll lose them
Hm, so you think it’s fine for now? The above does concern me, especially since we had in our docs the past month to not use .add with the backends option
e
v2 docs?
Or was that a rec for v1 too?
If v2 docs I'm fine with it - all still fluid.
👍 1
h
V2 docs. V1 docs has never mentioned V2
h
I'm fine with not being able to deregister that backend if it makes things easier.
It just seemed odd to me to single it out.
h
No difference for ease of implementation. Only comes down to whether this is a misfeature or not
Open in Slack
PreviousNext
Powered by