Ruby rewrite: Jewler to create a gem layout

[samrocketman]

This issue is to track rewriting gitlab-mirrors in ruby instead of bash. This way we get unit testing fun but still have the ability to subshell using back ticks if that's required.

19:25 < cosman2001> sag47, gitlab_mirrors would be simpler if it was a ruby CLI since it would have a single interface.
19:26 < sag47> cosman2001: Yeah, I've been looking for an excuse to flex my ruby muscles. I recently learned it and have been wanting to come up with a good project with it.
19:26 < sag47> It's basically bash on steroids and more.
19:26 < sag47> I like that it supports back ticks.
19:27 < sag47> Perhaps I'll figure out how to make gitlab-mirrors a gem.
19:27 < sag47> That's all future looking :)
19:28 < cosman2001> sag47, use jewler to auto create the gem layout and get to work. There are some good CLI gems that would help built an interface.
19:28 < sag47> cosman2001: Thanks for the advice, I'll start the project management on GitHub and add that as a ticket.

That's the nutshell from #gitlab on IRC freenode.

[logicminds]

I think the best approach here to to use the below gem to interface with. This dependency would be similar to python-gitlab3. But the gem below looks way better.

I would be willing to start this gem/rewrite for you but I won't be able to maintain it since I have committed to so many projects already. If you want create a new repo and give me permission to push and I'll get you started.

https://github.com/NARKOZ/gitlab

[samrocketman]

@logicminds Rather than that let's create a branch dedicated to the ruby rewrite. In that branch you can manipulate any files you want. I've added you as a contributor.

[logicminds]

I think it should just be a new repo. That way you can have a fresh start. Additionally if someone still wants the bash/python version its still intact.

[samrocketman]

@logicminds Please keep in mind that I adhere to the git flow workflow with this project. That means that master is production ready merges only.

[samrocketman]

Well for the bash/python implementation there's the prior versions that have been tagged (v0.1 through v0.5). So they can check out any of those versions and get the old implementation. Patches can still be made to those older versions if necessary.

I'd rather not fragment the project and just convert it into a gem.

[logicminds]

I don't think it would fragment the project. One is a ruby gem and the other is a set up scripts. Personally these are two different things that just take a similar approach Honestly, its best to have a new repo that way the gem version can match against the repo version. This is huge change and anybody using the current implementation would want to know. Maintaining each code base independently will may it simplier in the long run. The project should be called ruby-gitlab_mirrors

[samrocketman]

Fair enough, I've created https://github.com/samrocketman/gitlab-mirrors.rb

I've added you as a collaborator so you have RW access to it.

[samrocketman]

@logicminds since we can depend on rubygems.org for hosting stable versions I think it's okay to let master branch be bleeding edge development. Only published gems are the stable releases (with tags denoting which version is which).

[logicminds]

Sorry to nag. But this isn’t the “ruby standard”. It should be ruby-gitlab_mirrors. You Can you change to ruby-gitlab-mirrors too if you prefer.

I follow gitflow so regarding the comment above thats my normal workflow anyways.

[samrocketman]

Not nagging; I renamed the project to ruby-gitlab-mirrors. Is there a good place I can refer to look up ruby best practices or good conventions in ruby?

[samrocketman]

Since, I haven't really made any progress here and I'm probably not going to in the near future due to other interests... I'm going to abandon the thought of rewriting this in ruby.