Probably the proper solution is to compare against the latest version (including the version scheme), not all versions. https://github.com/Homebrew/homebrew-core/pull/6835#issuecomment-260132724 which @ilovezfs brought to my attention should also be resolved that way.
audit: "version should not decrease" check ignores version_scheme
=================================================================
Sample false positive: https://github.com/Homebrew/homebrew-core/pull/6863.
Code in question from `audit.rb`:
```rb
versions = attributes_map[:version].values.flatten
if !versions.empty? && formula.version < versions.max
problem "version should not decrease"
end
```
When `version_scheme` was bumped at some point, e.g., in the case of `pyenv`, `versions` will contain:
```
1.0.2
1.0.2
1.0.1
1.0.0
20160726
20160629
20160628
20160509
20160422
20160310
```
and a new version number like 1.0.3 will be smaller than `versions.max`.
> I'm sorry if the way I asked the questions implied an abrasive or confrontational tone, definitely not my intent.
No worries, let's get over the misunderstanding.
> I wasn't offended at all.
Okay, sorry.
> I was more confused as to why I ran the style/convention checker, fixed issues before opening the PR, to then be told I've more style issues that need to be addressed.
Well, again it's safe to ignore me, but I was just trying to help. Style check is only the minimum bar to clear, it's not unreasonable that people more familiar with the code base and its trends can suggest improvements.
In this specific case, you don't need to take my word for it. Just `grep -rI 'args ='` in the repo. You'll realize the majority uses my suggested style. There are some outliers, but if you blame them you'll realize they're generally code that hasn't changed in a long time.
> I was also trying to understand what I had missed, so that I could avoid needing more style fixes after opening a PR in the future.
I don't think having to push style fixes after opening a PR is shameful or anything. Again, I wasn't trying to judge you (and I'm not in the position to judge you), I was just trying to improve the code.
> For things like deciding which way to define Arrays of strings, you can absolutely alter Rubocop to enforce the style of the repo.
This does not conflict with "I doubt you can ask rubocop to flag configure_args in favor of args".
As for the way to define arrays of strings, I was talking specifically about the convention for defining the `args` array to `configure` (although I do believe `%W[]` or `%w[]` are generally preferred). Conventions aren't necessarily rules, and don't necessarily require enforcement, but it's nice to follow them for consistency.
> Knowing that the contribution guidelines require you to run rubocop to enforce style, and that this PR passed that check, do you feel this is absolutely a blocker on the PR?
I never said it's a blocker, and I only left a comment, not a "request changes". By the way I'm not even a maintainer at this point, so you can always ignore my opinions. But what's so hard about taking a (friendly, or at least neutral) piece of advice? Why are you offended, if I'm reading you correctly?
Well there's no point in enforcing everything. Experienced human beings are watching this repo, and should be able to point out things like this. (Also, I doubt you can ask rubocop to flag `configure_args` in favor of `args`.)
googler: remove the logging.shutdown exit handler
=================================================
Introduced in dfd3d5c. However,
1. The handler is registered at the wrong place.
2. We are logging with the standard stream handler to `sys.stderr`. `logging.shutdown` is useless in this case, because `sys.stderr` is automatically flushed and closed at exit (and `logging.shutdown` won't be able to close it anyway).
If you want to keep the `logging.shutdown` exit handler, it should be lifted, probably into the following group of global statements:
```py
# Set up logging
logging.basicConfig(format='[%(levelname)s] %(message)s')
logger = logging.getLogger()
```
or at least before the earliest point of exit.