I’ve begun brushing up the visibility design doc: ...
# development
c
I’ve begun brushing up the visibility design doc: https://docs.google.com/document/d/1DdVZ4DqX7uwiYuCL_ntb17yPxyez1fbiu8K0whZ78Lg/edit# with some new ideas. cc @happy-kitchen-89482 I’d like to hear what’s been cooking at your end too if you’ve started with anything in this area yet ?
The key points are to find something that hopefully scales well with larger repositories (I don’t think the prior idea with a visibility field would do that) and applying some experience from the
__defaults__
implementation.
w
Can I ask what inspires the dunder'd naming in the build files?
c
primarily to avoid confusing them from regular targets, indicative of being more of a build file “pragma” style of instruction.
w
As opposed to being?
Oh, like, top-level non-targets?
👍 1
I think I got confused, I thought I saw some of the dunders inside a
target
- but I might have just been mistaken
c
yeah, I’m not aware of any dunder fields..
Another topic worth considering from get-go is how to offer the visibility up to plugins for custom rule implementations.
p
Ooh. I like this proposal much better.
❤️ 1
making dependee vs dependency explicit is great.
👌 1
c
did I get them in the right direction too?!?
🎉 1
p
These are strictly path globs, right? ie a target address would be disallowed?
c
Yeah, I’d like to work with paths only
p
Yup. Looks good (right direction)
🙏 1
Now I’m itching to use these in the StackStorm repo to get rid of my regex-lint stuff… 😛
🤪 1
h
This may be a lost cause, but “dependee” isn’t a word, but to the extent that it means anything, it’s the thing being depended on, i.e., the “dependency”. So we’ve been using it wrong all along… The thing that depends on the dependency is a “dependent”.
Or maybe a “depender”
but “dependee” is at best ambiguous, and probably just wrong
p
https://www.pantsbuild.org/docs/reference-dependees We could use "dependent" but that might involve adding a new "dependents" goal (with "dependees" being a perpetual alias for it)...
h
And even the term “dependency” is probably being used unintuitively. In our parlance if A imports B, then B is a dependency of A. But in the real world, the “dependency” is the thing that needs the thing it depends on, and here it’s the other way around (A needs B).
So, gah
May as well not worry about it
p
So, my kids are my dependents - they depend on me. That would make me their dependency?
h
I think they are your dependencies! Like how the Faroe Islands are a dependency of Denmark
English is the worst language
p
amen
But poets love it because it can be so deliciously ambiguous.
A imports B • A depends on B • B is like the parent in the relationship • A is like the child in the relationship (think: things in A can subclass or inherit from things in B) • B is a dependency of A • A is a dependee of B ; A is a dependent of B I think dependee / dependent works.
We might need a note in the docs clarifying how we are using the terms, esp saying that "dependency" can be an ambiguous word in English, so this is how we are using it ...
I think the ambiguity comes because "dependency" in english does not have a direction. There is a dependency between A and B, but you need more prose to explain the nature of that dependency.
1
h
Yeah, I think “A imports B” means “B is a dependency of A” is easy enough to understand, even though it’s slightly unintuitive wrt the political geography meaning of dependency, but I doubt lots of people are going to go “what about the Faroe Islands, eh?”
But “dependee” is not a very useful word, and I am constantly having to remind myself which one it is. “Dependent” is more evocative? It’s more obviously “the thing that has the need of the other thing”?
We can change
--changed-dependees
to
--changed-dependents
and leave “dependees” as a forever alias
And the dependees goal
or we just embrace the error I suppose
p
Either way, we still need to spell that out more (maybe with a helpful infographic/chart) in the docs.
c
dependees -> dependents in the design doc. that looks nicer, I must say.
p
Yeah, but if we go with dependent here, then it is inconsistent with dependee everywhere else... It does look nicer with dependent though
c
agree.. so before we settle the visibility naming, it should be decided which direction we want to take this for the rest of the Pants project as well.
h
We can rename to dependent and just keep dependees as an alias for a very long time
It’s very cheap to do so
c
👍
OK, new PR for the revised visibility feature is ready for review: https://github.com/pantsbuild/pants/pull/17401