New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
query: expose is_executable
#15948
base: master
Are you sure you want to change the base?
query: expose is_executable
#15948
Conversation
It can be useful to know this, and currently the best proxy appears to be to look for `attributes.$is_executable` (which isn't documented), and or-ing that with a match on `rule_class.ends_with("_test")`. Instead, let's have a clearly documented API here.
Any ETA on merging this change? |
Not sure whether to route this to Core (@haxorz), Configurability (@gregestren), or Rules-API (@comius), so CCing TLs from all three. |
Since this is in the twilight zone between all these teams, I'll step in: why is this logic useful for you? This at least doesn't work with aliases (and can't, since So I don't immediately see how this is superior to looking at the |
It's mostly superior in terms of being documented (and, by being a proto-field, being self-documenting). As a consumer, it's currently unclear whether Also, being logic-free - right now the check is that a rule either has the I'd be happy to instead document |
I'd prefer the core technical parts of internal issues 28639562, 119498716, and 31180215 first get resolved then the Here's the [proposed] spec of
@illicitonion wdyt about this Due to some internal systems, implementing this This query function was never open-sourced in Bazel because of this tech debt. I prefer we resolve this tech debt.
Yeah, and ditto for the proposed |
Yes, a I don't have access to the internal bugs, but I'd be interested in the context of not wanting to support |
Cool, thanks for the info! I added a note to the internal issues.
Yeah I would be fine with
Yeah sorry for the lack of transparency. I gave those links mostly for @lberki and @brandjon. The context is that if |
Interesting - the thing that prompted me to file this PR is actually a very similar-sounding system: https://github.com/bazel-contrib/target-determinator - its goal is to be able to tell you which targets (that you care about) changed between two git commits. Roughly the form this tools operation takes is: Given some query pattern:
We do this at both the "before" and the "after" commit, and compare hashes to find the affected targets. I've seen a number of tools try to do similar analysis by crafting careful queries without actually winding back to the prior commit and performing the queries there too, and they have all missed important possible changes. Is that roughly what's going on in your internal tool too? I'd be curious as to ways we can generally making solving this kind of problem easier (either inside or outside of Bazel)... |
Yes, very interesting!
[Since I know the If Imagine
Yeah agree that this is using an algorithmic smell.
Similar goal but we take a bottom-up approach. Scale is too large for us to do the top-down approach of |
I've deleted my previous comments because they were inaccurate. This PR has no impact on Configurability and is a request for existing data to be exposed via the I see that @comius un-assigned this a few months ago: it should either be assigned to someone on that team or closed because we don't plan to merge it. Sorry for the confusion, @illicitonion. |
Is there still interest to get this in? |
Yeah, I'd happily get this merged - let me know if I should rebase |
It can be useful to know this, and currently the best proxy appears to
be to look for
attributes.$is_executable
(which isn't documented), andor-ing that with a match on
rule_class.ends_with("_test")
.Instead, let's have a clearly documented API here.