Skip to content

Instantly share code, notes, and snippets.

@MatheusRich
Last active September 3, 2019 18:37
Show Gist options
  • Save MatheusRich/48efd26a245f61c729cfe8bde6d8635c to your computer and use it in GitHub Desktop.
Save MatheusRich/48efd26a245f61c729cfe8bde6d8635c to your computer and use it in GitHub Desktop.
Google Summer of Code 2019 Work Product Submission

Google Summer of Code 2019 Report

Integrate functionality from gem-web into RubyGems gem CLI

Gem-web is a tool that capable of providing an interface that allows opening documentation, source code, and website of a ruby gem. My goal on GSoC was integrating it on RubyGems' CLI, which would make this feature available out of the box to all ruby users, improving their productivity, since there would have no need to search this information manually.

My Planning

I spent a good time in my proposal planning the work of every week in the GSoC period. So, I had, step-by-step, what to do, and when to do it. The task list was this:

  • Rewrite gem-web's tests with Minitest (because they were in Rspec).
  • Move the code of gem-web to Rubygems.
  • Make sure that the code worked in all platforms.
  • Open a Pull Request for Rubygems and get feedback from the community.
  • Adjust the code with the community recommendations.
  • Write tests for the (possible) changes the community asked for.
  • Make sure that the build is passing.
  • Write documentation about the changes I've made.

My Work & Results

Community Bounding

As soon as I was accepted to GSoC, I wrote an article on How I Got Accepted to GSoC, with some tips for the next possible GSoCers.

On the community bonding period, I wanted to study a bit on how Rubygems' commands work, so I dived into the code base and ended up writing a blog post about it.

Coding Period

All my work was done in my fork of Rubygems on the branch adds-web-command.

The first thing I did on the coding period, and after forking Rubygems, was opening an issue to address my work on it, and to get some feedback of the community before starting any code too. A couple of contributors (@hsbt and @indirect) commented on it, and I move on implementing the next steps.

I removed all the dependencies (development and runtime ones), and I rewrote gem-web's tests with Minitest, before moving the code itself (I followed a TDD approach).

After this, I started moving the code from gem-web to Rubygems. I created the file lib/rubygems/commands/web_command.rb, which contains the class Gem::Commands::WebCommand. This class defines the web command, its arguments, description, and usage.

The second file created was /lib/rubygems/executor.rb, which defines the class Gem::Web::Executor, that handles the arguments that the command receives and executes the corresponding action.

Since I removed Launchy, I wrote new methods to handle browser opening in all platforms, and now my code had no additional dependencies.

That was my first milestone, so I write a Pull Request Draft on my fork, just for my mentor take a look at my code and give some feedback. I made some adjusts and finally opened the Pull Request on Rubygems.

The community quickly sent me some comments about my approach to open the default browser, and I change the way it worked to something more stable and maintainable. Another modification was that the options for opening Github and Rubytoolbox were dropped. They made the feature too bound to third party services, so the community suggested me to take them off. (I wrote a post about this on my blog too, so you can check this out in more detail).

I've updated the code several times as the community asked me to change things. Some changes were big, others just code-style related. I updated the tests as well, matching the new behaviors, and I even wrote new ones.

As my code got stable (i.e., the contributors started to ask me to change only "small" things, mostly code style), I decided to go on and document everything I did. As usual, I wrote about it in my blog. This time I created two posts: the first one, where I talk about the web command, what it is, how to use it, and how it works; and a second post where I talk about all the process of contributing to Rubygems and what I've learned while doing it.

Aditya told me that I could add documentation for my feature at the Command Reference section of Rubygems' guides. I dug a bit on the Rubygems organization, and I found out that the documentation for the command would be automatically generated from the attributes I've used on Gem::Commands::WebCommand. So this means that once my PR is merged, the documentation will already exist. =D

So, at the end of the final evaluation, my code fulfills all my goals described at my proposal:

Just for remembering, the goals were: The final release should contain:

  • Stable code
    • Build is passing
    • 100% test coverage on the gem-web features
  • Changes Documented
  • Pull Request opened targeting the master branch

The build is currently passing, the tests cover all the code I've added, the feature is (automatically) documented, and the PR is opened.

What I Haven't Done & Future Work

I've done everything I proposed to do. The web command is now integrated into Rubygems (when the PR is merged, of course). Some of the features it had at gem-web couldn't make to the final release for community decisions, though.

As I future work, (because it was not in the scope of my proposal), I think that I could send a Pull Request to gem-web as well, updating its code to the "new" Rubygems command and making the Rubytoolbox and Github options available again.

Thanks

I have to thank Google so much for making this possible. I can’t describe how cool was this summer! It was a very cool experience! I also have to thank Ruby and Rubygems for guiding me all the way through this. Thanks for the contributors that reviewed my PR, and the support on Slack.

Saroj (@zoras), my mentor was just amazing! He always answered me as fast as he could, and made me find my way rather than giving me the answer right away! This was so nice! Thank you!

At last, I like to thanks all the people next to me that always encouraged me.

I definitively will keep contributing to Rubygems (and other Ruby projects too)! And yes, I want to participate again in the next edition of GSoC.

Important Links

Here are all the links related to my work in GSoC 2019:

  • Issue on Rubygems Github: Used to address my work on GSoC and get initial feedback from the community about this feature.
  • My Rubygems Fork: Where I did all my work.
  • DRAFT Pull Request: Used to get the first feedback of my mentor about my code.
  • Pull Request for Rubygems: The most important link. Here's the code I sent to Rubygems, all commits, and discussion with the contributors.
  • Blog Post #1: Talking about my proposal and some tips for future GSoCers.
  • Blog Post #2: Talking about how Rubygems commands work, and how to add a new one.
  • Blog Post #3: Talking about the web-command, the feature I've added, what it is, how to use it, and how it works.
  • Blog Post #4: Talking about all the process of contributing to Rubygems and what I've learned while doing it.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment