nchammas commented on PR #57010:
URL: https://github.com/apache/spark/pull/57010#issuecomment-4936045211

   > For the following, not really true for anyone uses SKIP_{something}=1 or 
SKIP_{something}=0 before.
   
   Anyone setting `SKIP_{something}=1` for docs will get the same behavior as 
before, and as far as I can tell our doc build infra doesn't explicitly set 
`SKIP_{something}=0` anywhere.
   
   [1]: 
https://github.com/apache/spark/blob/79026ad70380d6e92503ea27b1f61f484c63dc8b/dev/spark-test-image-util/docs/build-docs#L52
   
   For users running things interactively, the new `print_skip_flags` method 
prints a header that immediately makes it clear what flags are enabled for that 
run of the documentation build. So if someone is used to setting, for example, 
`SKIP_PYTHONDOC=0` during interactive runs, they'll get immediate feedback.
   
   In other words, the project's use of skip flags is fairly limited and 
resolving the various inconsistencies is a very tractable, if minor, problem.
   
   > I believe some part of this PR is not worthy enough to introduce those 
behavior changes as long as it works.
   
   I would like in a follow-up PR to update the various usages of `SKIP_` 
across the project to make their interpretation consistent. That is, we either 
have them all work as enabled when set to a specific value like `1` or `true`, 
or we have them all work as enabled when set to any non-empty string.
   
   It's a straightforward set of changes and will give us a convention to stick 
to going forward for build-related skip flags.
   
   Are you against this?


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: [email protected]

For queries about this service, please contact Infrastructure at:
[email protected]


---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]

Reply via email to