Why "require 'rubygems'" Is Wrong

http://tomayko.com/writings/require-rubygems-antipattern

by blasdel • 17 years ago

41 52 17 years ago

sunkencity3• 17 years ago

Stupid article.

So if I write a ruby program that needs rubygems I need to ask people that will run it to please run my program with "ruby -rubygems foo.rb" or set an environment variable, instead of just requiring the gems. Because that would infringe on the domain system administrator of that system. That doesn't make much sense to me.

robertduncan• 17 years ago

Agreed. I don't understand how require 'rubygems' is any less succinct than ruby -rubygems foo.rb.

masklinn12• 17 years ago

> So if I write a ruby program that needs rubygems

I think Ryan's point is that most of the time your program doesn't require rubygems itself. You just happen to manage your libraries using gems, somebody else could do it an other way (and never need rubygems), but you're forcing that person to install gems regardless.

sunkencity3• 17 years ago

Things tend to break a little less over time if I can require a version of a gem, like:

gem 'png', '= 1.1'

The good part about rubygems is that it's possible to get a certain version of a gem. I'd rather use gem and version than just require "png", and get god knows what version or file.

sho8• 17 years ago

I don't know who is voting you up? Maybe because you sound angry, and people associate angry technical rants with people who know what they're talking about?

"I think Ryan's point is that most of the time your program doesn't require rubygems itself."

Yeah! You could have manually downloaded the files for all the libraries you need, placed them in the directory, and required them directly. See, who needs rubygems? Oh hang on, rubygems is about 1000x easier than doing all that.

"You just happen to manage your libraries using gems"

Yes, because gems are the standard way of managing libraries in Ruby, and work transparently and conveniently. Where the hell is Ryan getting all these gem-using libraries anyway, if not from gems? And what is supposed to be wrong with it, anyway? I have never had a problem using a non-gem library even with gems present and a duplicate installed. Just require the non-gem lib first. What is so freaking hard? I assume it's some stupid problem he has to solve at Heroku - and his solution is trying to change how the entire Ruby community does things, to their detriment, benefiting only him. Screw him.

Oh well, anyway .. who cares. You're a crank and so is he. Rubygems is here to stay and if you don't like it .. well again, who cares.

anatoly• 17 years ago

Please don't start your shell scripts with #!/bin/sh. If a script foobar needs to be interpreted with sh, just run it with '/bin/sh foobar', instead of ./foobar.

Please don't put #include <stdlib.h> in your C source files. By doing this you remove my ability to compile your files in an environment where the standard library is not present. Instead, whenever you need to compile a file that uses stdlib.h functionality, simply use a small wrapper file that includes stdlib.h and then includes your source file, and compile that.

flooha2• 17 years ago

"Please don't start your shell scripts with #!/bin/sh...run it with '/bin/sh foobar', instead of ./foobar."

Are you serious?

adamc• 17 years ago

He's making an analogy to the article.

silentbicycle2• 17 years ago

Well, seriously, don't start your scripts with #!/bin/bash if you don't require any of bash's extra scripting functionality. (If you have to ask, you don't.) Bash isn't standard, sh is. It makes porting things other Unixes (e.g. the BSDs) easier. Not every Unix is Linux.

smanek2• 17 years ago

Incidentally, I've seen some people argue it's more portable to use '#!/usr/bin/env sh' than '#!/bin/sh'.

Most every machine I've been on has both /bin/sh and /usr/bin/env, so it's a bit of a non-issue: but does anyone know what the 'correct' shebang for a sh script is?

masklinn12• 17 years ago

Analogy failures:

* Configuring /bin/sh to point to my shell of choice is trivial (and common)

* Overriding the shebang is even more trivial, if I don't like sh, I can call `./mysupershell foobar`

Meanwhile, if I don't want gems on my machine and manage my $LOAD_PATH manually or through other means (which seems to be Ryan's case) but you decided that your library was going to require rubygems dammit, I have the choices between

* Installing rubygems (and duplicating my $LOAD_PATH handling efforts) anyway because you decided I was to have rubygems on my machine whether or not I liked it

* Adding an empty rubygems.rb to my $LOAD_PATH (yeah, kludge)

* Hacking Kernel#require to ignore gems request (yeah, horrible hack)

tptacek5• 17 years ago

If you're going to be in the tiny tiny minority of Ruby devs that insists on not installing rubygems, having a stubbed "rubygems.rb" in your load path is not an unreasonable request --- particularly compared to the request that everybody else uses some contorted command line to execute their script to accomodate you.

nanijoe• 17 years ago

Let me see...every time I have required rubygems it has done exactly what I intended for it to do (which is to allow me to load some ruby gem), so I think I'll just go ahead and ignore your advise.

patio11• 17 years ago

The system you use to manage your $LOAD_PATH is not my library / app / tests concern. Whether rubygems is used or not is an environment issue. My library or app should have no say in the matter. Explicitly requiring me to not use rubygems is either not necessary or misguided.

When you feel the urge to strike "require 'rubygems'" because some shit isn’t working, stop and consider whether one of these solutions is more appropriate:

1) An empty rubygems.rb in your $LOAD_PATH should do the trick.

2) Redefine Kernel#require to intercept calls to load rubygems and silently discard them.

Why You Shouldn't Force Non-Rubygems On People

When I write you a library, appplication, or tests, I may not want to have to care how you execute my program. When you require that I not include 'rubygems' in my code, you remove my ability to make that decision. I cannot anticipate all of your requirements in advance, but you can set up your environment properly such that the defaults I choose are overridden.

masklinn12• 17 years ago

So instead of separating the library and the environment you suggest that ugly hacks are more appropriate? Really?

tptacek5• 17 years ago

Having the 99.9% of ruby users who don't have a religious problem with rubygems all specify rubygems on the commandline seems like a more ugly hack than having the 3 developers in the world who care about this problem alter their environment.

ajkirwin• 17 years ago

Whoever this guy is, he really needs to pull his head out of his ass.

If someone's writing a library or app.. it's up to THEM whether they want to require rubygems or not. If you don't like how they do it.. then don't use their application/library, it's simple.

Most people create code for their OWN use and THEN publish it for others to use.

masklinn12• 17 years ago

> If someone's writing a library or app.. it's up to THEM whether they want to require rubygems or not.

But… why? Most of the time it's not like they actually need gems. They just happen to use gems as a $LOAD_PATH manager, so they're leaking their environment configuration into the library. How can anyone defend that?

It's like hardcoding the paths of dynamic libraries, or respawning your shell scripts because damn it if any god damn user is going to run it with anything other than /bin/bash.

It's completely insane.

sho8• 17 years ago

they just happen to use gems as a $LOAD_PATH manager

Oh come on. That's like saying "you should not make your MacOSX app require Finder just because some people just happen to use it as their file manager". Just happen? It's the default, and overwhelmingly dominant, choice! It's freaking bundled in 1.9 core!

rtomayko is a prominent and well regarded community member but he's pretty much a crank on this issue. He is the extreme odd one out who doesn't like rubygems, so it's on him to deal with it, rather than causing inconvenience for everyone else. He doesn't even give a good, or any, reason why he doesn't use gems. And as if I'm going to write -rubygems every time I run anything, give me a break.

Rubygems is the official package manager and is used without any issue by 99.9% of Rubyists. It's not 100% perfect but in general works beautifully and greatly contributes to making everything in Ruby "just work". There is no reason for people to stop using it as the default choice.

jon_dahl• 17 years ago

Whoever this guy is, he really needs to pull his head out of his ass.

The author is a smart guy. Major contributor to Sinatra, developer at Heroku, etc.

You might be right about the rubygems issue, but the random bile and personal attacks make it hard to take you seriously.

ionfish• 17 years ago

Context failure: linking to Ryan Tomayko's article without linking to the article that's brought it to people's attention again, namely Josh Peek's 'Gem Packaging: Best Practices'.

http://weblog.rubyonrails.org/2009/9/1/gem-packaging-best-pr...

Giles Bowkett has also written about the related issue of screwing up the load path:

http://gilesbowkett.blogspot.com/2009/04/unshiftfiledirnamef...

It's also worth noting that Ruby 1.9 requires rubygems automatically, as it's included in the standard library.

defunkt3• 17 years ago

Thanks! Both the Rubygems Bundler and Rip (as Josh explains) are great examples of why "require 'rubygems'" might not always be the best idea.

Bundler: http://github.com/wycats/bundler

Rip: http://hellorip.com/

jdminhbg• 17 years ago

This is called begging the question:

"Why You Shouldn’t Force Rubygems On People:

When I use your library, deploy your app, or run your tests I may not want to use rubygems."

toretore• 17 years ago

The point about not requiring rubygems in a library or a gem (as ironic as that may sound) is that by doing so you're coupling your implementation to your environment. This is as bad as coupling your classes to global constants, and not something you should do. Case in point: Rails allows you to "unpack" gems to make your app more portable, and it shouldn't matter if the "foo" gem uses the unpacked version or the one installed in the gem repository on the server.

Why "require 'rubygems'" Is Wrong

Related Stories