|
|
|
|
|
by latortuga
5356 days ago
|
|
As an RVM user, I wholeheartedly agree with your main point but I think there's an argument to be made to allow some other program handle gemsets. As it is, when you use RVM you most likely have to add your .rvmrc to your .gitignore. This unfortunately obfuscates what version of Ruby your project is on. Using rbenv is nice in that you can keep that documentation alongside the project where it belongs. Tying the gemset to the version is nice for testing various environments for a single project but doesn't work well when you have to choose between sharing a local development setting with the whole team or not sharing an rvmrc at all. |
|
Ruby is my go to language for damn near everything. I use it for working with log files, parsing Excel documents & performing analysis, system administration, you name it. Many of these scripts are one-offs that reside in '~/bin'. RVM allows you to do something like this in your shebang:
#!/usr/bin/env ruby-1.9.2-p290@vqm-analysis
That's the first line in a shell script that I wrote to collect examples of bad calls in a csv file output from an AdTran 900-series VoIP gateway. The CSV file contains about 30 columns of data related to the quality of VoIP calls. I have a collection of five or six scripts that use that gemset, but they're not really an application. They just run from '~/bin', so using bundler isn't really practical. I could wrap them up in a gem and make them a proper application, but this is scripting. Simply using RVM + gemsets saves me a lot of time.
My point is that gemsets may or may not have any utility for you, but it's narrow minded to assume that they have no utility for everyone.