MAmasklinn·Sep 3, 2009
> Not that it makes any sense arguing further, but for the record, I was not talking about libraries, I was talking about apps.
An app is a library is an app.
> Top level apps that need to require those libraries somehow.
And Ruby has a built-in method for that. It's called `require`. So if an app, a library, a script or whatever needs another library, it requires it and is done.
> I would have thought it was completely reasonable for top-level app authors to require rubygems
No. Unless the toplevel app is never distributed out of controlled environments (where you do impose rubygems) or expands gems in some way and therefore needs to hook into it (e.g. a GUI gems manager à la synaptic for apt-get) there is no need for rubygems at the app level.
The usage of rubygems (or the lack thereof) is part of the execution environment (the state o
Read the rest
f the machine the app is run on), not part of the application. Maybe for security reasons all libraries are deployed manually and $LOAD_PATH is handled likewise, maybe the guy uses bundler (http://github.com/wycats/bundler/tree/master) or rip (http://hellorip.com/) and doesn't want or need rubygems, maybe the user goes through his OS's package manager of choice (be it yum, apt-get, ports, …) because he likes having all package handling across his machine in a single place and piece, or maybe the app's user does indeed use rubygems. But as the application/script/library author, that's none of your business.
Requiring rubygems in your distributed code (unless you're in specific wrapper contexts or, once again, you're building on top of rubygems and expanding it in some way) means you're putting your nose where it doesn't belong: you're forcing environmental decisions on your users.
If you want to package your lib/app as a gems, that's fine and way cool of you, but that doesn't imply requiring rubygems at runtime.