-
Notifications
You must be signed in to change notification settings - Fork 209
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
Ruy 3.2 config #559
Comments
- Fixes standardrb#559 - Watched https://www.youtube.com/watch?v=8rLe_qmH84k - add latest Ruby
- Fixes standardrb#559 - Watched https://www.youtube.com/watch?v=8rLe_qmH84k - add latest Ruby
I can't remember the exact reason it's specified in base.yml at all, but I do remember that an esoteric and valid reason did/does exist. In any case, this value is overridden at runtime, as Standard determines on its own which version of Ruby to target (by default, the running See:
|
I think you missed a good chunk of the reasoning behind this report.
I am not using the standard run-time. I am following the evil martians guide to integrating standard and rubocop-gradual, see OP for links. rubocop-gradual has its own runtime.
That kind of reason frequently become sinvalid with the passage of time, and updates to external libraries or technologies. If you remember it, please document it! Perhaps there should be a wrapper gem to integrate standard and rubocop-gradual then... Perhaps I'll create a standard-gradual. Update - There is an open issue on rubocop-gradual to integrate with standard. |
- Fixes standardrb#559 - Watched https://www.youtube.com/watch?v=8rLe_qmH84k - add latest Ruby
If that's the case then you should be using config/base.yml, not config/default.yml. |
@searls I already am (for ruby-3.2 scenarios), and I never use
Sorry, I know you are super busy. Thanks for checking out the PR which directly addresses the issue I'm trying, and failing, to convey here! |
Turns out that a different wrapper is needed more than the I'm creating a wrapper/shim to house all the Ruby version'd RuboCop configs (https://rubocop-lts.gitlab.io/) I've enountered through upgrading Ruby 1.8 repos to Ruby 3.2 compatibility. It will load the ones from standard and then backfill all the ones that are missing. If you'd like I can create an issue for each rule I have that is missing from Standard, so they can be discussed for potential addition to Standard. But as I need this yesterday, I'm going to make a shim gem, the scope of which can be reduced if we can align on the additional rules. |
- Fixes standardrb#559 - Watched https://www.youtube.com/watch?v=8rLe_qmH84k - add latest Ruby
Released v1.0 of |
- Fixes #559 - Watched https://www.youtube.com/watch?v=8rLe_qmH84k - add latest Ruby
Thanks for following up. My apologies, I misread and therefore misunderstood what you were trying to do and how you were doing it. While referencing Standard's YAML files to be invoked by RuboCop is not supported, we won't say no to a no-op fix that prevents someone from having to repackage/build/wrap the tool in order to get it to work. These changes were released in standard@1.28.3 |
The default config appears to set a
TargetRubyVersion
of 2.6.The custom Ruby configs are available for Rubies 1.8 through 3.1, and for the most part they set the
TargetRubyVersion
as expected (exactly as expected).Why isn't there one of these custom configs for Ruby 3.2 now that it is released? Should we set
TargetRubyVersion
ourselves? Note that I am following Evil Martians' guide for setting up rubocop_gradual, and adding standard to that, so I am not using the regular config, but am loading standard and configs all manually.Is it merely that there hasn't been a PR to add it yet?
Why does this matter?
I get that each of the custom Ruby version configs inherit from the future Ruby version configs, and that the config for ruby 3.1 inherits from
base.yml
, such thatbase.yml
is implied to be the one that targets Ruby 3.2. However, it never does this explicitly, and for a project I am working on that is targeting 3.2 compatibility (more common with internal libraries, but also sometimes FLOSS ones) declairing it to be dependent onbase.yml
is a moving target.I'd rather have it fixed to the version of Ruby that the project itself is targeting (and again, AFAICT, the
standard.yml
config doesn't work in my use case, as I am usingrubocop_gradual
).Note: current release of
standard
already depends on the released version of RuboCop (1.50.2) that added support (experimental) for currentruby-head
(which is Ruby 3.3) viaTargetRubyVersion: 3.3
.Related...
❔ It might be cool if the
base.yml
targetedruby-head
! ... but even if not, it would still be great to have a file handle with the Ruby version to target in my projects even for the current relase of Ruby! <=== My PR does this.❔ If the
base.yml
did representruby-head
it would make sense that it is a moving target, because projects targeting ruby-head are much more likely to continue targeting ruby-head... forever, and thus they are more likely to want the moving target. <=== My PR does this (not explicitly, but so long as the if statement continues to grow with each minor release of Ruby).The text was updated successfully, but these errors were encountered: