Ruy 3.2 config

[pboling]

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 that base.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 on base.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 using rubocop_gradual).

Note: current release of standard already depends on the released version of RuboCop (1.50.2) that added support (experimental) for current ruby-head (which is Ruby 3.3) via TargetRubyVersion: 3.3.

Related...

❔ It might be cool if the base.yml targeted ruby-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 represent ruby-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).

[searls]

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 RUBY_VERSION, unless the user specifies a ruby_version in .standard.yml.

See:

standard/lib/standard/creates_config_store/sets_target_ruby_version.rb

Line 12 in 0739579

def call(options_config, standard_config)

[pboling]

I think you missed a good chunk of the reasoning behind this report.

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 RUBY_VERSION, unless the user specifies a ruby_version in .standard.yml

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.

an esoteric and valid reason did/does exist.

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.

[searls]

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.

If that's the case then you should be using config/base.yml, not config/default.yml.

[pboling]

@searls I already am (for ruby-3.2 scenarios), and I never use default.yml, and I am sorry that wasn't more clear. My contention is that base.yml should be strictly for ruby-head.

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 that base.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 on base.yml is a moving target.

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 represent ruby-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).

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!

[pboling]

Turns out that a different wrapper is needed more than the standard-gradual I propossed above.

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.

[pboling]

Released v1.0 of standard-rubocop-lts with the config shims. The only ones additional to what is already here are for Ruby 1.8.

[searls]

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 [email protected]