The "left-pad incident". Can it happen to ruby?


#1

For some context: http://www.haneycodes.net/npm-left-pad-have-we-forgotten-how-to-program/

What you guys think is the biggest problem, developers that over use external libraries? The npm infrastructure? Or the lack of such basic functions in the most popular language (if I’m not wrong) based on github repos?

Is there any “famous” gem that you are aware that uses some external library for some basic stuff like the left-pad module?


#2

I’ve had a similar experience when rails-assets.org went down for a while. I had depended on them for some gems since they automatically generate Ruby gems for Rails from JavaScript dependencies. So when their site went down I wasn’t able to deploy to production. I ended up needing to copy and paste from my local RVM copy into the projects vendor directory. I think they use npm to do this.

When I make gems I make it a point to not have dependencies whenever possible. My exception to this rule is when I add features or patches to other libraries.

I’m not aware of any libraries that would be comparable to the left-pad incident in Ruby. I do see people re-inventing small things that exist because they didn’t take the time to learn the tools available. But I don’t see those catching on.

For the record rails-assets.org is changing hosting. Their current deal ends at the end of this month March 31st, 2016 and they’re switching to Digital Ocean.


#3

The fewer dependencies each gem have is a big plus!
I generally believe that you want to make your dependency tree as small as possible.

Could this happen in the Ruby community? Sure, we all use bundler to package our gems and bundler uses https://rubygems.org/ to do this (separate projects). There was at one point where the amount of bundle install run actually caused a DDoS on https://rubygems.org/, causing every bundle install or bundle update to get a TimeoutError.

Andre Arko has a nice talk about it here: http://confreaks.tv/videos/goruco2013-deathmatch-bundler-vs-rubygems-org


#4

Relevant to this conversation: https://github.com/rubygems/rubygems.org/issues/1226


#5

I always try to roll my own than depend on a Gem for precisely things like this.

With regards to this specific problem tho, couldn’t there just be a grace period and a public list of gems (and their names) that have been pulled and have become ‘available’.

Maybe there should be a term that Gems can only be pulled with 6 months notice…


#6

I’m for a mirror solution. Redundant source hosting just like ftp mirrors and Linux distro repositories. I think it would be cool to have a Gemfile attribute per-gem/per-block-of-gems :in_case_of_emergency => 'http://lowbandwidth-backup-server.co' . I already use custom Github commits for many gems.

Here’s an example of me using Github private repo with commit versions for specific gems:

git "https://github.com/company/name-of-team.git" do
  gem 'automation_assistant', ref:  '19332'
  gem 'arel_eql_any', ref: '8886c'
end 

#7

Just as an FYI, it just happened. Fastlane team just removed gems from rubygems and broke builds that depended on it.

My initial workaround was to fix gems pointing to the github source, but that can vanish as well so I am starting to lean toward test using deployment mode for bundle install


#8

It is this reason alone why I will typically use a proxy between my rails app and rubygems.org. Not only does it help reduce server load on rubygems.org as it will store gem versions. It also helps mitigate a gem yank for whatever reason. While this can be good and bad in some situations. A gem version yank due to a major security violation is perfectly acceptable. It raises the red flag to a developer using that version of the gem if it isn’t already installed.

I believe a future version of rubygems will have this feature built in where you can have your own proxy server running whereas currently i’m using gemnasium.