Splitting out elvis into parts

[Licenser]

I would like to open a discussion about splitting out a 'core' elvis and then having that included in the webhook service or escript.

The idea is that it makes it easier to include and has less dependencies to worried about.

I came to this thought for two reasons:

1. I've build a little rebar3 plugin around elvis and it kind of icks me that things like jiffy, egithub, the webhooks etc are included there it feels just wrong
2. it would be wonderful if core-elvis could be published to hex to easyer include it in other things, which would be a lit easier with less dependencies :)

I'm happy to put some work into this if a PR for this would be accepted.

[elbrujohalcon]

Sounds like a good idea, @jfacorro: what do you think?

[Licenser]

Here is a WIP branch:

https://github.com/project-fifo/elvis/tree/elvis-core

I don't think merging it back to 'elvis' would make sense rather if it's accepted put it in a relvis_core repo?

[Licenser]

as a comparision a dependency tree of the rebar3 plugin with the upstream elvis:

└─ rebar3_lint─0.1.0 (project app)
   ├─ elvis─0.2.6-alpha1 (git repo)
   │  ├─ aleppo─0.1.0 (git repo)
   │  ├─ egithub─0.1.0-alpha (git repo)
   │  ├─ getopt─0.8.2 (git repo)
   │  ├─ ibrowse─4.1.2 (git repo)
   │  ├─ jiffy─0.14.3 (git repo)
   │  ├─ katana─0.2.13 (git repo)
   │  ├─ lager─2.0.0 (git repo)
   │  ├─ meck─0.8.2 (git repo)
   │  └─ zipper─0.1.2 (git repo)
   └─ goldrush─0.1.7 (hex package)

and with the elvis-core branch:

└─ rebar3_lint─0.1.0 (project app)
   ├─ elvis─0.2.6-alpha1 (git repo)
   │  ├─ aleppo─0.1.0 (git repo)
   │  ├─ katana─0.2.13 (git repo)
   │  ├─ lager─3.0.2 (hex package)
   │  └─ zipper─0.1.2 (git repo)
   └─ goldrush─0.1.7 (hex package)

[jfacorro]

I really like this idea 👍

[tsloughter]

👍 in a related note, would you be interested in a rebar.config.script that makes it so it can distinguish between rebar2 and rebar3? I'd like to publish your apps to hex.pm and that would allow it to be in sync with your repo instead of a fork.

[elbrujohalcon]

@tsloughter I'm not familiar enough with rebar to understand what you're proposing, but I'm all up for having elvis (and other inaka apps) published at hex.pm
What do we need to do?
We already have a hex.pm account, with which we published worker_pool.

[tsloughter]

Oh great! For elvis-core you'd need to publish aleppo, katana and zipper first, and any deps they might have. If you used erlang.mk's capability to generate the rebar.config you'll need to do something similar to https://github.com/benoitc/hackney/blob/master/rebar.config.script but instead of replacing deps if not rebar3 you'll need to do it for rebar3 and replace with the list of hex deps, like {deps, [aleppo, katana, lager, zipper]}. And the usual .app.src updates like you have for worker_pool.

[elbrujohalcon]

Ok, @jfacorro @Licenser : I'm about to create a new repo. Do you think it would be better to create elvis-core and move the core over there or to create elvis-extras and keep the core here?

[jfacorro]

@elbrujohalcon I think creating elvis_core would be a better approach since some people already come to this repo looking for elvis the tool.

[elbrujohalcon]

@Licenser @jfacorro : https://github.com/inaka/elvis_core , enjoy ❗

[Licenser]

@elbrujohalcon agreed, having a own repo for it seems the right move, also PR submitted for that with cleaned up elvis_core code :)

[jfacorro]

@elbrujohalcon @Licenser I think modifying elvis so that it uses elvis_core as a dependency should have top priority before any further work is done on elvis. This will make maintaining the code a lot easier, since otherwise we could have some improvements in elvis that don't get replicated in elvis_core and the other way around as well.