[yast-devel] Rubocop update?
Hi all, Some YaST projects already use Rubocop for checking the code style, but we froze the Rubocop version to 0.29.1 which is quite old these days (almost 1.5 year) and it produces some warnings with the latest common SUSE style [1] as it is written for newer versions. I have tried using the latest Rubocop (0.40.0) in some YaST projects to see how much work the upgrade would require and how much the code would change. ## Change it now? My first question is do we actually want to upgrade Rubocop *now*? IMHO it makes sense to upgrade it now. If we do it now it will save us some work later with SP2 maintenance when backporting the fixes from master. For the older branches (SP1 and older) we would stick with the old Rubocop. I.e. keep the version in the .travis.yml, for Jenkins we would build two versions of the Rubocop RPM in YaST:Head. And I expect that SP1 will need less and less fixes after SP2 is released. ## What would be actually changed? Here is a proposal for the upgrade. We need to update the default Rubocop config a bit [2] and then we need to adapt the code in all YaST projects which use Rubocop. I have started with the migration module which is small and written from scratch (i.e. no nasty YCP-Ruby code). The change was easy, everything was auto-corrected by Rubocop [3]. Then I tried yast2 which a big beast with a lot of YCP-Ruby code. You can see the change in [4]. It took me quite some time as not everything could be autocorrected... Note: I run each cop (check) in a separate commit so you can see what has been changed. On the other hand some changes require running more cops to be finished completely, e.g. a cop changes indentation of the code, but the comments are unchanged and are indented by a different cop later in a different commit. So I you see some strange or incomplete changes in a commit then check the final result (complete diff), it might be fixed in the end. Please check the pull requests and comment either there or here on the mailing list. ## Next Steps After we agree with the change and the updated style we can adapt the rest [5]. I guess it should rather easier as the most complex package (yast2) has been already adapted, the rest should be hopefully easier ;-) Thank you! Ladislav [1] https://github.com/SUSE/style-guides [2] https://github.com/yast/yast-devtools/pull/107 [3] https://github.com/yast/yast-migration/pull/34 [4] https://github.com/yast/yast-yast2/pull/478 [5] > find . -maxdepth 2 -name .rubocop.yml | sort ./bootloader/.rubocop.yml ./installation/.rubocop.yml ./journal/.rubocop.yml ./migration/.rubocop.yml ./network/.rubocop.yml ./nfs-client/.rubocop.yml ./rake-ci/.rubocop.yml ./rake/.rubocop.yml ./registration/.rubocop.yml ./rubocop-yast/.rubocop.yml ./ruby-bindings/.rubocop.yml ./storage-ng/.rubocop.yml ./yast2/.rubocop.yml -- Ladislav Slezák YaST Developer lslezak@suse.com SUSE -- To unsubscribe, e-mail: yast-devel+unsubscribe@opensuse.org To contact the owner, e-mail: yast-devel+owner@opensuse.org
On 06/20/2016 05:22 PM, Ladislav Slezak wrote:
Hi all,
Some YaST projects already use Rubocop for checking the code style, but we froze the Rubocop version to 0.29.1 which is quite old these days (almost 1.5 year) and it produces some warnings with the latest common SUSE style [1] as it is written for newer versions.
I have tried using the latest Rubocop (0.40.0) in some YaST projects to see how much work the upgrade would require and how much the code would change.
## Change it now?
My first question is do we actually want to upgrade Rubocop *now*?
IMHO it makes sense to upgrade it now. If we do it now it will save us some work later with SP2 maintenance when backporting the fixes from master.
Sounds reasonable.
For the older branches (SP1 and older) we would stick with the old Rubocop. I.e. keep the version in the .travis.yml, for Jenkins we would build two versions of the Rubocop RPM in YaST:Head. And I expect that SP1 will need less and less fixes after SP2 is released.
I indeed expect SP2 to be the first version of SLE12 to be massively used by customers. Adoption of GA and SP1 releases is usually not that high.
## What would be actually changed?
Here is a proposal for the upgrade. We need to update the default Rubocop config a bit [2] and then we need to adapt the code in all YaST projects which use Rubocop.
I have started with the migration module which is small and written from scratch (i.e. no nasty YCP-Ruby code). The change was easy, everything was auto-corrected by Rubocop [3].
Then I tried yast2 which a big beast with a lot of YCP-Ruby code. You can see the change in [4]. It took me quite some time as not everything could be autocorrected...
Note: I run each cop (check) in a separate commit so you can see what has been changed. On the other hand some changes require running more cops to be finished completely, e.g. a cop changes indentation of the code, but the comments are unchanged and are indented by a different cop later in a different commit.
So I you see some strange or incomplete changes in a commit then check the final result (complete diff), it might be fixed in the end.
Please check the pull requests and comment either there or here on the mailing list.
I'll check after oSC, Hackweek, etc.
## Next Steps
After we agree with the change and the updated style we can adapt the rest [5].
I guess it should rather easier as the most complex package (yast2) has been already adapted, the rest should be hopefully easier ;-)
Thank you!
Thank you!
Ladislav
[1] https://github.com/SUSE/style-guides [2] https://github.com/yast/yast-devtools/pull/107 [3] https://github.com/yast/yast-migration/pull/34 [4] https://github.com/yast/yast-yast2/pull/478 [5] > find . -maxdepth 2 -name .rubocop.yml | sort ./bootloader/.rubocop.yml ./installation/.rubocop.yml ./journal/.rubocop.yml ./migration/.rubocop.yml ./network/.rubocop.yml ./nfs-client/.rubocop.yml ./rake-ci/.rubocop.yml ./rake/.rubocop.yml ./registration/.rubocop.yml ./rubocop-yast/.rubocop.yml ./ruby-bindings/.rubocop.yml ./storage-ng/.rubocop.yml ./yast2/.rubocop.yml
--
Ladislav Slezák YaST Developer lslezak@suse.com SUSE
-- Ancor González Sosa YaST Team at SUSE Linux GmbH -- To unsubscribe, e-mail: yast-devel+unsubscribe@opensuse.org To contact the owner, e-mail: yast-devel+owner@opensuse.org
participants (2)
-
Ancor Gonzalez Sosa
-
Ladislav Slezak