The Contributor ends with a surprise twist!

Also, the story of how I overheated my laptop running the same command 100+ times

A New Challenger Appears

Previously, on The Contributor …

My project finalists are Gatsby, Visual Studio Code, and Electron. They’re all welcoming, super active, promising projects where I can see myself making meaningful contributions.

And now, to the finale:

The final project for the semester is …. none of the above!

I may have left out the fact that the winner of The Contributor must be a project that I can work on with a team. Though I may circle back to the projects mentioned in the previous weeks/episodes for my own personal contributions, the main project choice for this course also depends on input from my team members. Contributing to an open source project as a team changes the dynamic, since other developers’ strengths, weaknesses, and interests must now be factored in. This shouldn’t really come as a surprise though, given the inherent ‘working together’ nature of open source and the necessity of team work as a skill in tech in general. (The ‘show’ should really be titled The Contributors, but hindsight is always a clear solution. Perhaps a spinoff is due? …) Balancing this synthesis equation of skill sets as we work toward producing substantial contributions is part of the fun!

The Team: Move Over Fantastic Four, introducing the Thorough Three

I have the great opportunity to be teamed up with skilled developers and generally cool humans Daniel and Jessica for the semester. I’ll be interchangeably referring to them using their English and Github usernames (@dmallia17 and @wongjessica) from here on out. As project updates are pushed up each week, I encourage you to read their (very interesting) blog posts (if you haven’t been already) to get their perspectives on the various issues we come across and project-related topics discussed.

(Indecisiveness)^3

Even with all the benefits my team members brought, coming together only seemed to amplify individual indecisiveness when choosing a team project. To be fair, it is a semester long commitment and we wanted to be thorough when vetting potential choices. Unfortunately, this meant being the only team that hadn’t made a choice by the end of class on Monday, March 2nd — a class for which the main objective was each team having a project selected. What we did have, instead, was a narrowed down short list of candidates: Django, Visual Studio Code, and Atom. I also suggested Electron from my list to the team later in the week.

Elimination Round

Several projects were dropped over some long discussions and many texts throughout the week. Since we had already accounted for welcomeness and programming languages, the most important factor in consideration was a project’s potential for multiple substantial contributions accepted from us. This included the perceived learning curve, availability of accessible issues, and how smooth the development process seemed.

• Django and Electron were the first to go, on Thursday March 5th. The Django community uses an in house issue tracker, which was not too bad to navigate but just off-putting for the fact of being different from what we were already comfortable with. This wasn’t the deal breaker though. Issues tagged with easy pickings did not look very approachable, and on top of that none of us had experience developing on frameworks. Similar to Electron, the main use case for the project is creating other projects. For many bugs and features, we’d need some sort of sample project already using Django/Electron just to replicate the bug or try out the feature. Using a framework to build an app is very different from building on a framework itself. Perhaps some other team during some other semester.
• Finally, Visual Studio Code also fell under my team’s collective scrutiny. The VS Code repository has over 4,000 open issues, but the issues seem to be cluttered with user bug reports that have less to do with the functionality/documentation of the code editor itself and more individual case by case configuration problems (e.g app install complications, various operating system specific troubles). Though we all use Visual Studio Code as our main IDE, we also all use macOS devices, which would restrict our search area a lot.

The Meat of the Matter

By Friday we arrived at our final decision, the only project still standing: Atom, the hackable text editor. Though there’s a lack of currently open beginner friendly labeled issues, the issues in general looked approachable and accessible to us beginners. Atom is also more of its own end product, which means we will be able to run the app, test changes, and see the functionality occuring directly.

I must mention, though, that Atom is built using Electron (the science pun there writes itself ).

Attempting Nuclear Fusion (Building Atom from Source)

Daniel got a head start on the table-flipping   installation process, making the radical move to actually read through the flight manual documentation provided by Atom to get a preliminary feel for how the project is organized. We all agreed to start with the Hacking on Atom Core guide, and attempt to get a dev version of the core Atom application running. When first browsing the page, I noticed right away Python v2.7 being listed as a requirement. Even though it was technically in the ‘Running Core Tests” section, this stuck out as a potential problem to me because Python 2 was officially deprecated earlier this year, with many programs, packages, and applications making a move to Python 3. I highly suspected some sort of issue with dependencies might pop up due to this, but pushed on with installing nonetheless…

The Atom core installation instructions seem very simple and straightforward, since there there are only 2 commands to run after the typical fork/clone/cd into directory routine: script/bootstrap and atom --dev $PWD. These would respectively install all necessary dependencies, then set an environment variable so that the atom command would run Atom using the current local folder rather than the default install location.

How Not To Pull Yourself Up By Your Bootstrap

Since Daniel had already been on the front line, I had an idea of what the first error would be before even running the script myself — the newest versions of Node would not work when running script/bootstrap. The most current version of Node (as of this post) is 13, and the latest Active LTS version is 12, but the leveldown@4.0.2 (leveldown at version 4.0.2 specifically) dependency does not compile past Node 10. Daniel confirmed that he got further in the process by switching to an earlier Node version, and I found an issue in the Atom repository mentioning this specific problem that was also solved by changing versions.

What’s in a Version

Before this, I was loathe to simply switch Node versions to fix a dependency issue because most times the real problem has to do with the project itself not using the latest versions of dependencies. Deleting the package-lock.json file and re-installing with npm install usually fixes things. However, I haven’t worked with projects this large before, and I never really had to worry about integrating changes upstream in the past anyway. I’ve now realized my past approach is actually kind of ‘bad practice’ and only works in very specific cases. Ironically, projects can’t depend on the dependencies they use to always stay consistent in the latest versions with implementations, and sometimes it is just necessary to use an older, stabler version of a dependency to keep a project running smoothly. And thus, I finally made the plunge to start using nvm, a command line manager for Node versions. I have to say, I don’t think I’ll ever be looking back because so far it has been so easy to install and switch between different Node versions using nvm. It’s even recommended by Atom in the Hacking on Atom Core guide itself!

With the first hurdle over pretty quickly, I figured the install process should be pretty easy to handle from then on. I figured wrong.

A Wild Snake Chase

I ran script/bootstrap again and proceeded to spend an entire night trying to solve the next error that popped up. The error log itself would be longer than this entire blog post, but I’ll share two relevant snippets from it.

The first few lines in the error output, and the lowest level of the issue:

ERROR:root:code for hash md5 was not found.
Traceback (most recent call last):
  File "/usr/local/Cellar/python@2/2.7.15_2/Frameworks/Python.framework/Versions/2.7/lib/python2.7/hashlib.py", line 147, in <module>
    globals()[__func_name] = __get_hash(__func_name)
  File "/usr/local/Cellar/python@2/2.7.15_2/Frameworks/Python.framework/Versions/2.7/lib/python2.7/hashlib.py", line 97, in __get_builtin_constructor
    raise ValueError('unsupported hash type ' + name)
ValueError: unsupported hash type md5

and the high level node output related to the dependency the script was failing on:

npm ERR! oniguruma@6.2.1 install: `prebuild-install || node-gyp rebuild`
npm ERR! Exit status 1
npm ERR! 
npm ERR! Failed at the oniguruma@6.2.1 install script.

The first thing I did was search ‘oniguruma install’ in the atom repo, which only yielded one relevant issue. The user who opened #18540 did not have the same exact error as me, but had a similar situation where all the requirements were correct (Python 2 is still the default version for the python command for me) but script/bootstrap was failing. Contributors in the thread eventually realized the problem was that Atom had to be previously installed for the bootstrap script to correctly work, which shouldn’t happen. A user should be able to fork and clone the repository and build directly from source. (It’s me, I’m ‘a user’). I was hopeful because my teammates didn’t have this problem with bootstrapping, and they had Atom previously installed whereas I did not. However, it was fixed for everyone else in the thread in a PR that removed node-gyp as a dependency. The issue didn’t really help solve my problem, but it did give insight into what was going on behind the scenes of the bootstrap script.

Being right back at square one, I tried several approaches:

• Maybe it’s the oniguruma dependency?
  I quickly dismissed this after a short search, since a popular regular expression library used in several languages and applications probably didn’t have anything to do with my installation woes. There are barely any issues in the project’s repository, so it seems oniguruma itself is stable and not the source of the error.
• Maybe it’s a node-gyp issue?
  I tried to search to see if it was the node-gyp version somehow using incorrectly using python, and even installed node-gyp globally to see if anything would change. Not only did it not change anything, but it also didn’t make sense in hindsight since node-gyp was removed as a dependency, and as such the version is now built in with the bootstrap install command, overriding the globally installed version. node-gyp was not the problem.
• Maybe Python 2 isn’t being used correctly on my machine?
  I double and triple checked the Python version being used in the command line (python -V), and started messing around with the PATH variable to try to force Python 2 to show up first and ensure it was being recognized. Python 2 was being used and was installed in the correct location, so this also wasn’t the problem.

Though none of the approaches solved my problem or changed the error that occurred, I did learn a lot about the many different libraries, tools, and systems along the way.

The Colors at the End of the Tunnel

In a final hail mary, I started duckduckgoing the error text in the first snippet looking for any possible solutions. In the process of refining my search and trying out different suggestions from stackoverflow posts and github issues in other places, I ran a long overdue brew upgrade - which upgrades the packages installed using brew - that took over a half hour to run. And then, FINALLY, after several hours of the same error message mocking me every time I ran script/bootstrap, this stackoverflow post provided a solution that fixed the problem. I followed the first answer, and after running the first two commands to fix brew linking of the openssl library, script/bootstrap ran without errors !

In the moment, it seemed like a completely unrelated, random library had been causing the problem. Later on, after some thought (and some sleep), I would find a way to put it together: the oniguruma dependency failed to install due to the python hashlib module being unable to load because the correct openssl version wasn’t linked in brew. I may have to revisit this in the future just for my own sense of understanding, because parts of the situation still go over my head.

Beautiful, errorless output (Just ignore those warnings)

Though I wasn’t yet out of the woods (see the ‘atom unknown’ in the image), the rest of the way was smooth sailing. I ran atom --dev with my current directory path passed in as an argument, and then script/build --install to install Atom Dev as an app on my Mac. At long last, I ran the atom command, and the editor popped up, built from source. The journey was finally over just beginning.

Installing the dev environment took up this whole week, so look out for possible issues next time!

The Periodic Table of Contributions

I haven’t had much time to make other contributions this week (unfortunately, I have responsibilities besides messing with open source). Instead I’ll share my plans for upcoming contributions, along with what symbols I think each type of contribution would have if it was an element.

• OpenStreetMap (Om): Light Weight, Nonreactive
  • There are several shops and buildings I can easily add in a 2 block radius around the Hunter Brookdale campus, and furthermore my trip to nearby Little India is overdue.
  • I’m also considering buckling down and learning to use the more advanced JOSM editor to see if I can procedurally add all Citibike Stations in the city to the map, but that task presents a multitude of issues and may just be impossible. Still …
• Wikipedia (Wk): Light Weight, Nonreactive
  • I have not touched upon Wikipedia edits or Wikipedia as a platform at all yet, so I’ll be looking into that in the near future.
• Blog Edits (Bg): Light Weight, Slightly Reactive
  • My colleagues are writing about interesting things and I will be keeping watch for typos and grammar while reading about them.
• Project Documentation (Dc): Medium Weight, More Reactive
  • For any documentation I come across I’ll be keeping an eye out for typos, lack of detail, or misleading sections.
  • I will probably open an issue for the DuckDuck Go Privacy Extension project I evaluated last week related to some issues I had while installing that the documentation could be clearer on.
• Project Code (Cd): Heavy Weight, Highly Reactive
  • Hopefully I will be able to take some time and look into projects that stuck out to me during the run of The Contributor, and make some of my own personal contributions to them.

A little update on my only merged code contribution so far: it’s live! See an example here — the email for this place is a link! Even though it’s a small change, it’s cool to see it on an actual website that I now use often. This means I can stop refreshing the site every other day.

These posts are getting pretty long, I might need to start using a Table of Contents soon …

Onward and inward!