GSoC Phase 2

4-minute read
debian • open-source
debian • gsoc

Hello,

In early May, I got selected as a Google Summer of Code student for Debian to work on a project which is to write a linter (an extension to RuboCop).
This tool is mostly to help the Debian Ruby team. And that is the best part, I love working in/for/with the Ruby team!
(I’ve been an active part of the team for 19 months now :))

More details about the project can be found here, on the wiki.
And also, I have got the best mentors I could’ve possibly asked for: Antonio Terceiro and David Rodríguez 💖

So, the program began on 1st June and I’ve been working since then. I log my daily updates at gsocwithutkarsh2102.tk.
The blog for the first part of phase 1 can be found here and that of second part of phase 1 can be found here.

Whilst the daily updates are available at the above site^, I’ll breakdown the important parts here:

  • After the, what I’d like to call, successful Phase 1, whilst using this extension on GitLab’s omnibus-gitlab repository, I discovered a bug (as reported via issue #5), which basically threw the following error:

    An error occurred while Packaging/GemspecGit cop was inspecting /home/utkarsh/github/omnibus-gitlab/files/gitlab-cookbooks/gitlab/recipes/bootstrap_disable.rb.
    To see the complete backtrace run rubocop -d.

    …which was not good.

  • This bug was a false-negative and the fix turned out to be simple, which was raised via PR #6.
    Since the extension was now working fine against omnibus-gitlab (which is…quite huge!), I rolled out a v0.1.1 release! 🎉

  • Next, I implemented the 2nd cop, fixing require and require_relative calls which map from spec(s)/test(s) to the lib directory.
    This was raised via a WIP PR #4.

  • We had our meeting where we discussed that it would rather make sense to split these cops into two parts and also, thanks to David’s elaborative comment on the situation.
    With this, we decided to split the cops into two.

  • Then I worked on:

  • At this point, we hit yet another obstacle. Correctly determining the root directory of a project at runtime. This is…tricky. Not impossible (of course) but tricky.
    So my “homework” was to find such a thing that does that by default.

  • For the next 4 days, I tried to find something that could do this bit. But unfortunately, I couldn’t.
    So I wrote one myself. I wrote get_root, which solves this problem.
    The only thing that one needs to take care while using get_root is that it has to be a git repository. That’s a…trade-off.

  • In the next meeting, we discussed that this is a bit of an overkill. get_root should’ve been written as a helper function and not as another library, which David and Antonio pointed out correctly. But it was already too late :P
    I had already made a v 0.1.0 release.
    (So in case you’re a Rubyist and want to find the root directory of a git repository, consider using this :P)
    Besides, Antonio also pointed out that it should take another arguement as to from point from where the file is being inspected. Hm, unsure how to do that..

  • Meanwhile, I exported get_root as a helper function, David solved all the problem altogether at once via rubocop’s PR #8314.
    This introduced a new (public) method #project_root which superseeded get_root and one could now get the root directory via RuboCop::ConfigLoader.project_root. Ain’t he amazing!? \o/

  • This also means, I reverted those changes altogether and tweaked my WIP PR to inculcate these changes via commit @b06a8f86.
    However, the specs fail. But that doesn’t mean that the changes aren’t correct :P
    They are pretty much right and working fine. To make that sure, I locally installed this library and used on other projects to make sure that it indeed is working alright, as it should! \o/

  • And here I am on the 15th day :)

Well, the best part yet?
rubocop-packaging is being used by batalert, arbre, rspec-stubbed_env, rspec-pending_for, ISO8601, get_root (😛), gir_ffi, linter, and cucumber-rails.

Whilst it has been a lot of fun so far, my plate has started to almost…overflow. It seems that I’ve got a lot of things to work on (and already things that are due!).
From my major project, college *stuff to my GSoC project, Debian (E)LTS, and a lot *more.

Thanks to Antonio for helping me out with *other things (which maps back to his sayings in Paris \o/).

Until next time.
:wq for today.