Rubocop enhancements for foreman plugins - your opinion is needed

As we all know, foreman core uses rubocop for enforcing style rules. Many
plugins, especially those that are in theforeman organization, use rubocop
too.
The problem is, that the rules are not unified between foreman core and
plugins. In addition to that when rubocop version changes in core, core's
rules change accordingly, but plugins remain often with the old ruleset for
no reason.

I am suggesting inheriting foreman's ruleset as a base ruleset for plugins.
I have found two ways to accomplish that:

  1. Rubocop has an option to inherit a remote URL [1]
    <https://github.com/bbatsov/rubocop/blob/master/manual/configuration.md#inheriting-configuration-from-a-remote-url>,
    so we can point a plugin to github URL for foreman master ruleset [2]
    <https://raw.githubusercontent.com/theforeman/foreman/develop/.rubocop.yml>.

Advantages: it's simple.
Disadvantages: You have to be connected in order to download the file
(Although rubocop has caching mechanism for it)
2. We can utilize another Rubocop config option: inheriting the settings
from a gem [3]
<https://github.com/bbatsov/rubocop/blob/master/manual/configuration.md#inheriting-configuration-from-a-dependency-gem>.
This will require us to create a special development gem, that would be
used by foreman core and plugins. This gem will contain a proper ruleset.
I am a bit biased, since I have already started foreman_devel plugin [4]
<https://github.com/ShimShtein/foreman_devel> that should help plugin
developers in multiple tasks.
Advantages: It's a plugin that can do a lot more than just ruleset repo.
It's versioned properly. It's offline, once you have the gem installed.
Disadvantages: Extra gem. Installation is more complicated. Affects the
core too

I would like to hear your opinions about the issue. Both whether you like
the basic idea of inheriting the same ruleset and if so, which is the
preferred way to go.

Shim,

[1]


[2]
https://raw.githubusercontent.com/theforeman/foreman/develop/.rubocop.yml
[3]

[4] https://github.com/ShimShtein/foreman_devel

sshtein@redhat.com writes:

> As we all know, foreman core uses rubocop for enforcing style rules. Many
> plugins, especially those that are in theforeman organization, use rubocop
> too.
> The problem is, that the rules are not unified between foreman core and
> plugins. In addition to that when rubocop version changes in core, core's
> rules change accordingly, but plugins remain often with the old ruleset for
> no reason.
>
> I am suggesting inheriting foreman's ruleset as a base ruleset for plugins.
> I have found two ways to accomplish that:
>
> 1. Rubocop has an option to inherit a remote URL [1]
> <https://github.com/bbatsov/rubocop/blob/master/manual/configuration.md#inheriting-configuration-from-a-remote-url>,
> so we can point a plugin to github URL for foreman master ruleset [2]
> <https://raw.githubusercontent.com/theforeman/foreman/develop/.rubocop.yml>.
>
> Advantages: it's simple.
> Disadvantages: You have to be connected in order to download the file
> (Although rubocop has caching mechanism for it)
> 2. We can utilize another Rubocop config option: inheriting the settings
> from a gem [3]
> <https://github.com/bbatsov/rubocop/blob/master/manual/configuration.md#inheriting-configuration-from-a-dependency-gem>.
> This will require us to create a special development gem, that would be
> used by foreman core and plugins. This gem will contain a proper ruleset.
> I am a bit biased, since I have already started foreman_devel plugin [4]
> <https://github.com/ShimShtein/foreman_devel> that should help plugin
> developers in multiple tasks.
> Advantages: It's a plugin that can do a lot more than just ruleset repo.
> It's versioned properly. It's offline, once you have the gem installed.
> Disadvantages: Extra gem. Installation is more complicated. Affects the
> core too
>
> I would like to hear your opinions about the issue. Both whether you like
> the basic idea of inheriting the same ruleset and if so, which is the
> preferred way to go.

Another approach could be, in the .rubocop.yml of the plugin, expecing
there will be foreman on ../foreman and including ../foreman/.rubocop.ymlin the plugin
and using rubocop via running rake from the foreman repo (we already
have rake foreman_remote_execution:rubocop for example). I guess this
assumption of the layout of plugin development is reasonable to make (it
would work also with the CI).

The benefits would be not needing to do anything with the current
approach in the core (that I guess works for the core), while the
plugins using it as base. It would not need to require the downloading
from outside. Also it would take into account the versioning and we
would not have issues with running rubocop against foreman/plugin stable
branches, that I guess should stay with the configuration there was at
the time of branching.

– Ivan

··· > > Shim, > > > > [1] > https://github.com/bbatsov/rubocop/blob/master/manual/configuration.md#inheriting-configuration-from-a-remote-url > [2] > https://raw.githubusercontent.com/theforeman/foreman/develop/.rubocop.yml > [3] > https://github.com/bbatsov/rubocop/blob/master/manual/configuration.md#inheriting-configuration-from-a-dependency-gem > [4] https://github.com/ShimShtein/foreman_devel > > -- > You received this message because you are subscribed to the Google Groups "foreman-dev" group. > To unsubscribe from this group and stop receiving emails from it, send an email to foreman-dev+unsubscribe@googlegroups.com. > For more options, visit https://groups.google.com/d/optout.

> expecing there will be foreman on ../foreman and including
../foreman/.rubocop.ymlin the plugin
I wanted to avoid hard assumptions about folders layout (since the task
simply won't run at all if foreman folder is located elsewhere).

> using rubocop via running rake from the foreman repo
Doesn't help for build automation - You can't enable automatic builds this
way.

> It would not need to require the downloading from outside.
You are still downloading/refreshing foreman's repo. It's the same as
getting the file by URL.

> not needing to do anything with the current approach in the core
If you are that concerned about core changes, we can always duplicate the
file - core stays as is, and plugins are getting the file from development
gem. It will just require a synchronization with the core once in a while.

··· On Tue, Jan 24, 2017 at 12:08 PM, Ivan Necas wrote:

sshtein@redhat.com writes:

As we all know, foreman core uses rubocop for enforcing style rules. Many
plugins, especially those that are in theforeman organization, use
rubocop
too.
The problem is, that the rules are not unified between foreman core and
plugins. In addition to that when rubocop version changes in core, core’s
rules change accordingly, but plugins remain often with the old ruleset
for
no reason.

I am suggesting inheriting foreman’s ruleset as a base ruleset for
plugins.
I have found two ways to accomplish that:

  1. Rubocop has an option to inherit a remote URL [1]
    <https://github.com/bbatsov/rubocop/blob/master/manual/
    configuration.md#inheriting-configuration-from-a-remote-url>,
    so we can point a plugin to github URL for foreman master ruleset [2]
    <https://raw.githubusercontent.com/theforeman/foreman/develop/.
    rubocop.yml>.

Advantages: it’s simple.
Disadvantages: You have to be connected in order to download the file
(Although rubocop has caching mechanism for it)
2. We can utilize another Rubocop config option: inheriting the
settings
from a gem [3]
<https://github.com/bbatsov/rubocop/blob/master/manual/
configuration.md#inheriting-configuration-from-a-dependency-gem>.
This will require us to create a special development gem, that would
be
used by foreman core and plugins. This gem will contain a proper
ruleset.
I am a bit biased, since I have already started foreman_devel plugin
[4]
https://github.com/ShimShtein/foreman_devel that should help plugin
developers in multiple tasks.
Advantages: It’s a plugin that can do a lot more than just ruleset
repo.
It’s versioned properly. It’s offline, once you have the gem
installed.
Disadvantages: Extra gem. Installation is more complicated. Affects
the
core too

I would like to hear your opinions about the issue. Both whether you like
the basic idea of inheriting the same ruleset and if so, which is the
preferred way to go.

Another approach could be, in the .rubocop.yml of the plugin, expecing
there will be foreman on ../foreman and including
../foreman/.rubocop.ymlin the plugin
and using rubocop via running rake from the foreman repo (we already
have rake foreman_remote_execution:rubocop for example). I guess this
assumption of the layout of plugin development is reasonable to make (it
would work also with the CI).

The benefits would be not needing to do anything with the current
approach in the core (that I guess works for the core), while the
plugins using it as base. It would not need to require the downloading
from outside. Also it would take into account the versioning and we
would not have issues with running rubocop against foreman/plugin stable
branches, that I guess should stay with the configuration there was at
the time of branching.

– Ivan

Shim,

[1]
https://github.com/bbatsov/rubocop/blob/master/manual/
configuration.md#inheriting-configuration-from-a-remote-url
[2]
https://raw.githubusercontent.com/theforeman/foreman/
develop/.rubocop.yml
[3]
https://github.com/bbatsov/rubocop/blob/master/manual/
configuration.md#inheriting-configuration-from-a-dependency-gem
[4] https://github.com/ShimShtein/foreman_devel


You received this message because you are subscribed to the Google
Groups “foreman-dev” group.
To unsubscribe from this group and stop receiving emails from it, send
an email to foreman-dev+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Shimon Shtein <sshtein@redhat.com> writes:

>> expecing there will be foreman on ../foreman and including
> ../foreman/.rubocop.ymlin the plugin
> I wanted to avoid hard assumptions about folders layout (since the task
> simply won't run at all if foreman folder is located elsewhere).

It would be on plugin maintainers decision.

>
>> using rubocop via running rake from the foreman repo
> Doesn't help for build automation - You can't enable automatic builds this
> way.

Why? We already do this in REX https://gitlab.cee.redhat.com/egolov/asciidoctor-ej/blob/vodafone-sat6/Vodafone-Satellite6-Capsule.adoc

>
>> It would not need to require the downloading from outside.
> You are still downloading/refreshing foreman's repo. It's the same as
> getting the file by URL.

It's not: you have the rubocop versioned and you can switch between
versions quickly.

>
>> not needing to do anything with the current approach in the core
> If you are that concerned about core changes, we can always duplicate the
> file - core stays as is, and plugins are getting the file from development
> gem. It will just require a synchronization with the core once in a
> while.

Not convinced about benefits of additional layer.

– Ivan

··· > > On Tue, Jan 24, 2017 at 12:08 PM, Ivan Necas wrote: > >> sshtein@redhat.com writes: >> >> > As we all know, foreman core uses rubocop for enforcing style rules. Many >> > plugins, especially those that are in theforeman organization, use >> rubocop >> > too. >> > The problem is, that the rules are not unified between foreman core and >> > plugins. In addition to that when rubocop version changes in core, core's >> > rules change accordingly, but plugins remain often with the old ruleset >> for >> > no reason. >> > >> > I am suggesting inheriting foreman's ruleset as a base ruleset for >> plugins. >> > I have found two ways to accomplish that: >> > >> > 1. Rubocop has an option to inherit a remote URL [1] >> > > configuration.md#inheriting-configuration-from-a-remote-url>, >> > so we can point a plugin to github URL for foreman master ruleset [2] >> > > rubocop.yml>. >> > >> > Advantages: it's simple. >> > Disadvantages: You have to be connected in order to download the file >> > (Although rubocop has caching mechanism for it) >> > 2. We can utilize another Rubocop config option: inheriting the >> settings >> > from a gem [3] >> > > configuration.md#inheriting-configuration-from-a-dependency-gem>. >> > This will require us to create a special development gem, that would >> be >> > used by foreman core and plugins. This gem will contain a proper >> ruleset. >> > I am a bit biased, since I have already started foreman_devel plugin >> [4] >> > that should help plugin >> > developers in multiple tasks. >> > Advantages: It's a plugin that can do a lot more than just ruleset >> repo. >> > It's versioned properly. It's offline, once you have the gem >> installed. >> > Disadvantages: Extra gem. Installation is more complicated. Affects >> the >> > core too >> > >> > I would like to hear your opinions about the issue. Both whether you like >> > the basic idea of inheriting the same ruleset and if so, which is the >> > preferred way to go. >> >> Another approach could be, in the .rubocop.yml of the plugin, expecing >> there will be foreman on `../foreman` and including >> `../foreman/.rubocop.yml`in the plugin >> and using rubocop via running rake from the foreman repo (we already >> have `rake foreman_remote_execution:rubocop` for example). I guess this >> assumption of the layout of plugin development is reasonable to make (it >> would work also with the CI). >> >> The benefits would be not needing to do anything with the current >> approach in the core (that I guess works for the core), while the >> plugins using it as base. It would not need to require the downloading >> from outside. Also it would take into account the versioning and we >> would not have issues with running rubocop against foreman/plugin stable >> branches, that I guess should stay with the configuration there was at >> the time of branching. >> >> -- Ivan >> >> > >> > Shim, >> > >> > >> > >> > [1] >> > https://github.com/bbatsov/rubocop/blob/master/manual/ >> configuration.md#inheriting-configuration-from-a-remote-url >> > [2] >> > https://raw.githubusercontent.com/theforeman/foreman/ >> develop/.rubocop.yml >> > [3] >> > https://github.com/bbatsov/rubocop/blob/master/manual/ >> configuration.md#inheriting-configuration-from-a-dependency-gem >> > [4] https://github.com/ShimShtein/foreman_devel >> > >> > -- >> > You received this message because you are subscribed to the Google >> Groups "foreman-dev" group. >> > To unsubscribe from this group and stop receiving emails from it, send >> an email to foreman-dev+unsubscribe@googlegroups.com. >> > For more options, visit https://groups.google.com/d/optout. >>

Ivan Necas <inecas@redhat.com> writes:

> Shimon Shtein <sshtein@redhat.com> writes:
>
>>> expecing there will be foreman on ../foreman and including
>> ../foreman/.rubocop.ymlin the plugin
>> I wanted to avoid hard assumptions about folders layout (since the task
>> simply won't run at all if foreman folder is located elsewhere).
>
> It would be on plugin maintainers decision.
>
>>
>>> using rubocop via running rake from the foreman repo
>> Doesn't help for build automation - You can't enable automatic builds this
>> way.
>
> Why? We already do this in REX
> https://gitlab.cee.redhat.com/egolov/asciidoctor-ej/blob/vodafone-sat6/Vodafone-Satellite6-Capsule.adoc

Sry, the right link is


:slight_smile:

– Ivan

··· > >> >>> It would not need to require the downloading from outside. >> You are still downloading/refreshing foreman's repo. It's the same as >> getting the file by URL. > > It's not: you have the rubocop versioned and you can switch between > versions quickly. > >> >>> not needing to do anything with the current approach in the core >> If you are that concerned about core changes, we can always duplicate the >> file - core stays as is, and plugins are getting the file from development >> gem. It will just require a synchronization with the core once in a >> while. > > Not convinced about benefits of additional layer. > > -- Ivan > >> >> On Tue, Jan 24, 2017 at 12:08 PM, Ivan Necas wrote: >> >>> sshtein@redhat.com writes: >>> >>> > As we all know, foreman core uses rubocop for enforcing style rules. Many >>> > plugins, especially those that are in theforeman organization, use >>> rubocop >>> > too. >>> > The problem is, that the rules are not unified between foreman core and >>> > plugins. In addition to that when rubocop version changes in core, core's >>> > rules change accordingly, but plugins remain often with the old ruleset >>> for >>> > no reason. >>> > >>> > I am suggesting inheriting foreman's ruleset as a base ruleset for >>> plugins. >>> > I have found two ways to accomplish that: >>> > >>> > 1. Rubocop has an option to inherit a remote URL [1] >>> > >> configuration.md#inheriting-configuration-from-a-remote-url>, >>> > so we can point a plugin to github URL for foreman master ruleset [2] >>> > >> rubocop.yml>. >>> > >>> > Advantages: it's simple. >>> > Disadvantages: You have to be connected in order to download the file >>> > (Although rubocop has caching mechanism for it) >>> > 2. We can utilize another Rubocop config option: inheriting the >>> settings >>> > from a gem [3] >>> > >> configuration.md#inheriting-configuration-from-a-dependency-gem>. >>> > This will require us to create a special development gem, that would >>> be >>> > used by foreman core and plugins. This gem will contain a proper >>> ruleset. >>> > I am a bit biased, since I have already started foreman_devel plugin >>> [4] >>> > that should help plugin >>> > developers in multiple tasks. >>> > Advantages: It's a plugin that can do a lot more than just ruleset >>> repo. >>> > It's versioned properly. It's offline, once you have the gem >>> installed. >>> > Disadvantages: Extra gem. Installation is more complicated. Affects >>> the >>> > core too >>> > >>> > I would like to hear your opinions about the issue. Both whether you like >>> > the basic idea of inheriting the same ruleset and if so, which is the >>> > preferred way to go. >>> >>> Another approach could be, in the .rubocop.yml of the plugin, expecing >>> there will be foreman on `../foreman` and including >>> `../foreman/.rubocop.yml`in the plugin >>> and using rubocop via running rake from the foreman repo (we already >>> have `rake foreman_remote_execution:rubocop` for example). I guess this >>> assumption of the layout of plugin development is reasonable to make (it >>> would work also with the CI). >>> >>> The benefits would be not needing to do anything with the current >>> approach in the core (that I guess works for the core), while the >>> plugins using it as base. It would not need to require the downloading >>> from outside. Also it would take into account the versioning and we >>> would not have issues with running rubocop against foreman/plugin stable >>> branches, that I guess should stay with the configuration there was at >>> the time of branching. >>> >>> -- Ivan >>> >>> > >>> > Shim, >>> > >>> > >>> > >>> > [1] >>> > https://github.com/bbatsov/rubocop/blob/master/manual/ >>> configuration.md#inheriting-configuration-from-a-remote-url >>> > [2] >>> > https://raw.githubusercontent.com/theforeman/foreman/ >>> develop/.rubocop.yml >>> > [3] >>> > https://github.com/bbatsov/rubocop/blob/master/manual/ >>> configuration.md#inheriting-configuration-from-a-dependency-gem >>> > [4] https://github.com/ShimShtein/foreman_devel >>> > >>> > -- >>> > You received this message because you are subscribed to the Google >>> Groups "foreman-dev" group. >>> > To unsubscribe from this group and stop receiving emails from it, send >>> an email to foreman-dev+unsubscribe@googlegroups.com. >>> > For more options, visit https://groups.google.com/d/optout. >>>

> It would be on plugin maintainers decision.
What would be a maintainers decision? The fact that the task will run only
on some setups? IMHO It's a bit annoying.

About the automation, my solution basically removes both
foreman_remote_execution:rubocop and the enhancement (And deleting code is
even better than writing one :wink: ).
Plus you get a straight forward way of running rubocop as a developer: You
don't have to run a rake task from a parent project, you just run rubocop
from your current folder.

IMHO, It's simpler solution for devs…

··· On Tue, Jan 24, 2017 at 6:37 PM, Ivan Necas wrote:

Ivan Necas inecas@redhat.com writes:

Shimon Shtein sshtein@redhat.com writes:

expecing there will be foreman on ../foreman and including
../foreman/.rubocop.ymlin the plugin
I wanted to avoid hard assumptions about folders layout (since the task
simply won’t run at all if foreman folder is located elsewhere).

It would be on plugin maintainers decision.

using rubocop via running rake from the foreman repo
Doesn’t help for build automation - You can’t enable automatic builds
this

way.

Why? We already do this in REX
https://gitlab.cee.redhat.com/egolov/asciidoctor-ej/blob/
vodafone-sat6/Vodafone-Satellite6-Capsule.adoc

Sry, the right link is
https://github.com/theforeman/foreman_remote_execution/blob/
master/lib/tasks/foreman_remote_execution_tasks.rake#L44
:slight_smile:

– Ivan

It would not need to require the downloading from outside.
You are still downloading/refreshing foreman’s repo. It’s the same as
getting the file by URL.

It’s not: you have the rubocop versioned and you can switch between
versions quickly.

not needing to do anything with the current approach in the core
If you are that concerned about core changes, we can always duplicate
the

file - core stays as is, and plugins are getting the file from
development

gem. It will just require a synchronization with the core once in a
while.

Not convinced about benefits of additional layer.

– Ivan

On Tue, Jan 24, 2017 at 12:08 PM, Ivan Necas inecas@redhat.com wrote:

sshtein@redhat.com writes:

As we all know, foreman core uses rubocop for enforcing style rules.
Many

plugins, especially those that are in theforeman organization, use
rubocop
too.
The problem is, that the rules are not unified between foreman core
and

plugins. In addition to that when rubocop version changes in core,
core’s

rules change accordingly, but plugins remain often with the old
ruleset

for

no reason.

I am suggesting inheriting foreman’s ruleset as a base ruleset for
plugins.
I have found two ways to accomplish that:

  1. Rubocop has an option to inherit a remote URL [1]
    <https://github.com/bbatsov/rubocop/blob/master/manual/
    configuration.md#inheriting-configuration-from-a-remote-url>,
    so we can point a plugin to github URL for foreman master ruleset
    [2]

<https://raw.githubusercontent.com/theforeman/foreman/develop/.
rubocop.yml>.

Advantages: it’s simple.
Disadvantages: You have to be connected in order to download the
file

(Although rubocop has caching mechanism for it)
2. We can utilize another Rubocop config option: inheriting the
settings
from a gem [3]
<https://github.com/bbatsov/rubocop/blob/master/manual/
configuration.md#inheriting-configuration-from-a-dependency-gem>.
This will require us to create a special development gem, that
would

be

used by foreman core and plugins. This gem will contain a proper
ruleset.
I am a bit biased, since I have already started foreman_devel
plugin

[4]

https://github.com/ShimShtein/foreman_devel that should help
plugin

developers in multiple tasks.
Advantages: It’s a plugin that can do a lot more than just ruleset
repo.
It’s versioned properly. It’s offline, once you have the gem
installed.
Disadvantages: Extra gem. Installation is more complicated.
Affects

the

core too

I would like to hear your opinions about the issue. Both whether you
like

the basic idea of inheriting the same ruleset and if so, which is the
preferred way to go.

Another approach could be, in the .rubocop.yml of the plugin, expecing
there will be foreman on ../foreman and including
../foreman/.rubocop.ymlin the plugin
and using rubocop via running rake from the foreman repo (we already
have rake foreman_remote_execution:rubocop for example). I guess
this

assumption of the layout of plugin development is reasonable to make
(it

would work also with the CI).

The benefits would be not needing to do anything with the current
approach in the core (that I guess works for the core), while the
plugins using it as base. It would not need to require the downloading
from outside. Also it would take into account the versioning and we
would not have issues with running rubocop against foreman/plugin
stable

branches, that I guess should stay with the configuration there was at
the time of branching.

– Ivan

Shim,

[1]
https://github.com/bbatsov/rubocop/blob/master/manual/
configuration.md#inheriting-configuration-from-a-remote-url
[2]
https://raw.githubusercontent.com/theforeman/foreman/
develop/.rubocop.yml
[3]
https://github.com/bbatsov/rubocop/blob/master/manual/
configuration.md#inheriting-configuration-from-a-dependency-gem
[4] https://github.com/ShimShtein/foreman_devel


You received this message because you are subscribed to the Google
Groups “foreman-dev” group.
To unsubscribe from this group and stop receiving emails from it,
send

an email to foreman-dev+unsubscribe@googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

Shimon Shtein <sshtein@redhat.com> writes:

>> It would be on plugin maintainers decision.
> What would be a maintainers decision? The fact that the task will run only
> on some setups? IMHO It's a bit annoying.
>
> About the automation, my solution basically removes both
> foreman_remote_execution:rubocop and the enhancement (And deleting code is
> even better than writing one :wink: ).
> Plus you get a straight forward way of running rubocop as a developer: You
> don't have to run a rake task from a parent project, you just run rubocop
> from your current folder.
>
> IMHO, It's simpler solution for devs…

That is matter of opinion: people already need to run unit tests from
the foreman directory. Anyway, I've tried to express my opinions on
this. For me the original proposal doesn't work very well and given
nobody else joined discussion, there is not much interested in changing
this in the ecosystem itself.

– Ivan

··· > > > > On Tue, Jan 24, 2017 at 6:37 PM, Ivan Necas wrote: > >> Ivan Necas writes: >> >> > Shimon Shtein writes: >> > >> >>> expecing there will be foreman on `../foreman` and including >> >> `../foreman/.rubocop.yml`in the plugin >> >> I wanted to avoid hard assumptions about folders layout (since the task >> >> simply won't run at all if foreman folder is located elsewhere). >> > >> > It would be on plugin maintainers decision. >> > >> >> >> >>> using rubocop via running rake from the foreman repo >> >> Doesn't help for build automation - You can't enable automatic builds >> this >> >> way. >> > >> > Why? We already do this in REX >> > https://gitlab.cee.redhat.com/egolov/asciidoctor-ej/blob/ >> vodafone-sat6/Vodafone-Satellite6-Capsule.adoc >> >> Sry, the right link is >> https://github.com/theforeman/foreman_remote_execution/blob/ >> master/lib/tasks/foreman_remote_execution_tasks.rake#L44 >> :) >> >> -- Ivan >> >> > >> >> >> >>> It would not need to require the downloading from outside. >> >> You are still downloading/refreshing foreman's repo. It's the same as >> >> getting the file by URL. >> > >> > It's not: you have the rubocop versioned and you can switch between >> > versions quickly. >> > >> >> >> >>> not needing to do anything with the current approach in the core >> >> If you are that concerned about core changes, we can always duplicate >> the >> >> file - core stays as is, and plugins are getting the file from >> development >> >> gem. It will just require a synchronization with the core once in a >> >> while. >> > >> > Not convinced about benefits of additional layer. >> > >> > -- Ivan >> > >> >> >> >> On Tue, Jan 24, 2017 at 12:08 PM, Ivan Necas wrote: >> >> >> >>> sshtein@redhat.com writes: >> >>> >> >>> > As we all know, foreman core uses rubocop for enforcing style rules. >> Many >> >>> > plugins, especially those that are in theforeman organization, use >> >>> rubocop >> >>> > too. >> >>> > The problem is, that the rules are not unified between foreman core >> and >> >>> > plugins. In addition to that when rubocop version changes in core, >> core's >> >>> > rules change accordingly, but plugins remain often with the old >> ruleset >> >>> for >> >>> > no reason. >> >>> > >> >>> > I am suggesting inheriting foreman's ruleset as a base ruleset for >> >>> plugins. >> >>> > I have found two ways to accomplish that: >> >>> > >> >>> > 1. Rubocop has an option to inherit a remote URL [1] >> >>> > > >>> configuration.md#inheriting-configuration-from-a-remote-url>, >> >>> > so we can point a plugin to github URL for foreman master ruleset >> [2] >> >>> > > >>> rubocop.yml>. >> >>> > >> >>> > Advantages: it's simple. >> >>> > Disadvantages: You have to be connected in order to download the >> file >> >>> > (Although rubocop has caching mechanism for it) >> >>> > 2. We can utilize another Rubocop config option: inheriting the >> >>> settings >> >>> > from a gem [3] >> >>> > > >>> configuration.md#inheriting-configuration-from-a-dependency-gem>. >> >>> > This will require us to create a special development gem, that >> would >> >>> be >> >>> > used by foreman core and plugins. This gem will contain a proper >> >>> ruleset. >> >>> > I am a bit biased, since I have already started foreman_devel >> plugin >> >>> [4] >> >>> > that should help >> plugin >> >>> > developers in multiple tasks. >> >>> > Advantages: It's a plugin that can do a lot more than just ruleset >> >>> repo. >> >>> > It's versioned properly. It's offline, once you have the gem >> >>> installed. >> >>> > Disadvantages: Extra gem. Installation is more complicated. >> Affects >> >>> the >> >>> > core too >> >>> > >> >>> > I would like to hear your opinions about the issue. Both whether you >> like >> >>> > the basic idea of inheriting the same ruleset and if so, which is the >> >>> > preferred way to go. >> >>> >> >>> Another approach could be, in the .rubocop.yml of the plugin, expecing >> >>> there will be foreman on `../foreman` and including >> >>> `../foreman/.rubocop.yml`in the plugin >> >>> and using rubocop via running rake from the foreman repo (we already >> >>> have `rake foreman_remote_execution:rubocop` for example). I guess >> this >> >>> assumption of the layout of plugin development is reasonable to make >> (it >> >>> would work also with the CI). >> >>> >> >>> The benefits would be not needing to do anything with the current >> >>> approach in the core (that I guess works for the core), while the >> >>> plugins using it as base. It would not need to require the downloading >> >>> from outside. Also it would take into account the versioning and we >> >>> would not have issues with running rubocop against foreman/plugin >> stable >> >>> branches, that I guess should stay with the configuration there was at >> >>> the time of branching. >> >>> >> >>> -- Ivan >> >>> >> >>> > >> >>> > Shim, >> >>> > >> >>> > >> >>> > >> >>> > [1] >> >>> > https://github.com/bbatsov/rubocop/blob/master/manual/ >> >>> configuration.md#inheriting-configuration-from-a-remote-url >> >>> > [2] >> >>> > https://raw.githubusercontent.com/theforeman/foreman/ >> >>> develop/.rubocop.yml >> >>> > [3] >> >>> > https://github.com/bbatsov/rubocop/blob/master/manual/ >> >>> configuration.md#inheriting-configuration-from-a-dependency-gem >> >>> > [4] https://github.com/ShimShtein/foreman_devel >> >>> > >> >>> > -- >> >>> > You received this message because you are subscribed to the Google >> >>> Groups "foreman-dev" group. >> >>> > To unsubscribe from this group and stop receiving emails from it, >> send >> >>> an email to foreman-dev+unsubscribe@googlegroups.com. >> >>> > For more options, visit https://groups.google.com/d/optout. >> >>> >> > > -- > You received this message because you are subscribed to the Google Groups "foreman-dev" group. > To unsubscribe from this group and stop receiving emails from it, send an email to foreman-dev+unsubscribe@googlegroups.com. > For more options, visit https://groups.google.com/d/optout.