Vendor Everything? Not so fast...

Posted about 1 month ago

I remember in early 2007 reading Chris Wanstrath’s excellent post Vendor Everything.

The idea behind “Vendor Everything” is to DRY up your development environment, and prevent external dependencies from slowing down your development process. I think, as a contractor, this is an excellent idea. Generally, you are in control of the version control system and you may find yourself interfacing with people in different timezones who aren’t always religious about reading their e-mail or being on IM regularly.

Much like anything else, sometimes you have to know when to follow advice and when to stray from the golden path. “Vendor Everything” is one of those things that works great in certain situations, and not so much in others.

The article hit me especially hard because I was in the tail end of working for a company that made extensive use of subversion externals, long before piston existed or most people even knew svn externals existed. We were struggling to keep our Rails applications synchronized between branches and releases (two to three times a week for nearly a year), and finding the “Vendor Everything” concept to be a headache.

Fast forward a year and a half, and I am getting ready to leave another company. We initially used Subversion, and flirted with the idea of using Piston to maintain the loads of plugins we would ultimately use. About 3 months in, everything changed and the company went in a different direction, buying Perforce and requiring all projects be immediately moved to it. If you’ve ever used Perforce, it doesn’t lend itself much to the “Vendor Everything” mind set, and I’d imagine a tool such as Piston does not exist for Perforce (I could be totally wrong).

After using Merb for a while, and with Rails 2.1 coming out with gem dependencies, I’m liking the idea of Geming everything. Rails has some holes in it that don’t make things easy (Rake tasks are not automatically loaded from gems, for example), but for the most part the process is very straightforward and really makes a lot of sense.

Plugins to me were always second class citizens; they weren’t really gems, and we created external, tool dependent mechanisms to version them, when Rubygems already had a built-in mechanism to deal with versioning. Plugins still don’t have a dependency mechanism, so one plugin cannot state which other plugins it depends on to run, although Gems have supported this for a long time. Plus, what happens when you want to use a plugin outside of Rails? It becomes a gem anyways. Let’s just end the madness and make it a gem to begin with.

Commenting is closed

3 days later Raphael added:

Sorry if this is OT, but I just see you’ve taken down railsapi.org (which was a pretty nifty resource). Any chance it might go online again one way or another?

In any case, thanks for putting it online in the first place! :-)