https://pantsbuild.org/ logo
Join Slack
Powered by
Oof that's a tough one: the main file for Sphinx i...
# development
h
Oof that's a tough one: the main file for Sphinx is 
conf.py
. 
tailor
is going to think that should be 
python_sources
, along with default 
sources=
for 
python_sources
✅ 1
How can we fix 
tailor
so things Just Work? Particularly tricky is that 
pants.backend.python
isn't supposed to know about 
pants.backend.python.docs.sphinx
It's almost like we want a mechanism to say "I weakly want to own this. If something else wants it more, yield"
b
This goes back to my thought of the sources field having plugin-installed dependent values 😮
c
I’m thinking of having a hook in tailor where it calls out with source files and asks to have it classified to an owning target type, with some default fallback behaviour. So when the sphinx backend is enabled, it can override it for 
conf.py
, where as when it isn’t, it’ll just be a regular 
python_sources
coke 1
h
This goes back to my thought of the sources field having plugin-installed dependent values
It'd be useful, but I think would make things like our auto-generated docs complex on what the default for 
python_sources
etc is I fear a world where our online docs != the behavior in your own repo
c
Oh, wait. I forgot how tailor works. So now, each backend gives a list of putative targets. So what if those targets are associated with a priority value, then tailor can just choose the target with the highest prio for targets that cover the same source files.
h
exactly, that's what the issue proposes
c
Ah, right. coke ? 😛
Only, with 
weak=False
it’s not as granular… 😉z
h
only maybe simpler modeling: 
weak: bool
. If 
weak=True
, give up if something else is trying to create it Which avoids having to sync numbers across different backends (gives me CSS 
!important
vibes hehe)
this is the first instance we know of with a conflict like this, so I generally would bias towards simpler modeling. but unclear what to do!
c
what if there’s two backends that say 
weak=False
for the same target..
also, was the priority sentence in there in the PR from the beginning? didn’t see it until now! 😮
I don’t think my head operates any more… time to sign off… 😉
h
heh yeah it was, no edits. but no worries, I do that a lot too
what if there’s two backends that say weak=False for the same target..
yeah, that's a weird one. it results in no one generating a target. But also, how realistic do we think it is that will happen?
idk, maybe priority is the easiest approach. I only don't like the idea of trying to guess what # to use. And that you accidentally use the same value as another backend w/o realizing
c
I’m in favour of prio values, even if it’ll require having some sort of scheme to it (could mask it by using constants a la log levels) like 
prio=WEAK
prio=STRONG
prio=NAH
etc…
h
Late to the conversation here, but the idea is that we'd want 
conf.py
to be tailored as some sphinx-related target?
I mean, it sounds like there should be a 
python_sources
for 
conf.py
because it is a python source
but then maybe also a sphinx related target that points to it?
Similar to how 
pex_binary
doesn't have its own sources?
h
I doubt it, but maybe. It's a special config file and I doubt we want it participating in dep inference etc
b
Even later. Without python_sources owning it, would we lose formatting+linting? Also dep inference should be fine right? Either the user doesn't need it so whatever, or they're doing funny things and they do. Why should pants kneecap them?
Also I'm really struggling to find a case where there's be multiple weak and no strong. Maybe for some extension less file? Even still there's almost always a precedent. And if we find out we're wrong we can assign numerical priority to weak/strong for backwards compat
h
If 
python_source
owns it, then we need to: • now make sure it's in a source root • deal with missing imports like 
alabaster
(at least according to https://pythonhosted.org/CodeChat/conf.py.html), triggering 
unowned_dependency_behavior
I literally didn't know this file existed a week ago, so very much not an expert. But fwict, we do not want 
python_source
to own this Now, running Black on it would be awesome. But I think we need to rethink FieldSets to make that happen, such that we can say to run Black but not MyPy and Pylint etc
👍 1
Also I'm really struggling to find a case where there's be multiple weak and no strong.
It's all fairly contrived at this point. We've gone a year w/ 
tailor
and this is our first instance.
Even still there's almost always a precedent.
And if we find out we're wrong we can assign numerical priority to weak/strong for backwards compat
Are you suggesting sticking w/ 
weak: bool
, or using numbers?
👍 1
b
Maybe an enum? Then the values can be switched to int if needed
h
how so? like we could go to 
WEAK
, 
NORMAL
, 
STRONG
?
b
Weak and strong to start, but yeah.
👍 1
c
I’m OK with enums.
(not that I’ll be upset if you choose to go with the 
bool
option either.. though)
Open in Slack
PreviousNext
Powered by