4 ms·

That's exactly why I don't like ruby. A ruby app usually does not integrate very well with other ruby apps on the system. Especially when company policy mandate

by __mp 12y ago

That's exactly why I don't like ruby. A ruby app usually does not integrate very well with other ruby apps on the system. Especially when company policy mandates that system ruby versions need to be used. /rant It's my experience that ruby applications usually require the $latest ruby version. Getting it to run properly with other ruby (diva) applications is just a pain. This is especially annoying if the applications are managed with a deployment tool like puppet. Applying $PATH quirks to get a nice and consistent layout on these machines is not really the solution. Now, your solution whilst certainly being neat just creates another intermediate layer. I'm not sure if this is the solution. How do people manage the os updates on docker images? How how do people handle application updates? What if I want to define that in a sane manner? With puppet I can define a nice and sane process that handles everything from installation to updates to the removal of an app. I have a clear history and I'm able to see what is going on on the machine. I also have a defined and clear process to update the machines. I'm just guessing but I don't think that your solution is going to work for gitlab without applying a couple of patches to the source files. Routing SSH through port 22 of the host system is going to be a real pain. It also makes future updates a cheerful occurrence. Nowadays I mostly do development in C, C++ and C# (OSX/Windows and some embedded stuff). Whenever I hear `ruby` or `gem` I start running :) I also had similar problems with a Go application recently (can you guess which one?).

krisdol 12y ago
Unless you're still on ruby 1.8 (long in the tooth), I don't see how ruby apps from newer versions of ruby will have any trouble integrating with other apps. I can understand a 2.1 app not working on 1.9 or 2.0 in some cases, but backwards compatibility is not the problem. Forwards compatibility is not really a feature of any mainstream language that I know of. I'm really saddened that there are IT departments that mandate system ruby, though. There isn't even a system ruby on Windows.
FooBarWidget 12y ago
Traveling Ruby is not meant to be used by users to package up an existing app. It's meant to be used by app developers to package up their apps. You would never use Traveling Ruby to package up Gitlab; instead, Gitlab HQ might use Traveling Ruby to package up Gitlab. I'm not sure who your rant is targeted at. Traveling Ruby is meant to solve exactly the problem that you're ranting about. Developers use Traveling Ruby to create a package that is self-contained, and no further dependencies, and doesn't conflict with any of the stuff that is already installed. Think of a Traveling Ruby-packaged app as a single exe. Not physically (because the package consists of multiple files), but spiritually/conceptually (because as a user, you only run a single file, and the result doesn't conflict with anything else on the system). You can compare it spiritually to Go. Go produces single binaries with no dependencies, that you can just run. You can still integrate this stuff with Puppet or Chef or whatever; Traveling Ruby doesn't stop you from doing that, not makes it harder for you.

by __mp 12y ago

krisdol 12y ago

Unless you're still on ruby 1.8 (long in the tooth), I don't see how ruby apps from newer versions of ruby will have any trouble integrating with other apps. I can understand a 2.1 app not working on 1.9 or 2.0 in some cases, but backwards compatibility is not the problem. Forwards compatibility is not really a feature of any mainstream language that I know of. I'm really saddened that there are IT departments that mandate system ruby, though. There isn't even a system ruby on Windows.

FooBarWidget 12y ago

Traveling Ruby is not meant to be used by users to package up an existing app. It's meant to be used by app developers to package up their apps. You would never use Traveling Ruby to package up Gitlab; instead, Gitlab HQ might use Traveling Ruby to package up Gitlab. I'm not sure who your rant is targeted at. Traveling Ruby is meant to solve exactly the problem that you're ranting about. Developers use Traveling Ruby to create a package that is self-contained, and no further dependencies, and doesn't conflict with any of the stuff that is already installed. Think of a Traveling Ruby-packaged app as a single exe. Not physically (because the package consists of multiple files), but spiritually/conceptually (because as a user, you only run a single file, and the result doesn't conflict with anything else on the system). You can compare it spiritually to Go. Go produces single binaries with no dependencies, that you can just run. You can still integrate this stuff with Puppet or Chef or whatever; Traveling Ruby doesn't stop you from doing that, not makes it harder for you.