Hacker News Reader

Comment by alrs | Hacker News Reader

Yes. Rubygems is the project that was run as amateur hour, not Debian.

EDIT: And before anyone mentions it: http://marc.info/?l=openssl-dev&m=114652287210110&w=...

I'm not sure it's worth stirring this up again, the different viewpoints are already clearly discussed at https://news.ycombinator.com/item?id=2059964, and the Debian Ruby maintainers have made several policy changes since then.

After trying to install a rails app on Ubuntu , frankly the entirety of ruby and its notion of how a mature language should be packaged is pure amateur hour. Rvm is a mess, the various versions are a mess. For example v1.9.3 appears to be considered the same as 1.9.1, and random bugs appear when moving between versions. WTF?

I don't understand your issues with Ruby on Ubuntu, setting it up with RBenv is fairly simple, you can see my build script here: https://gist.github.com/kaspergrubbe/5383877

About 1.9.3 and 1.9.1 are you sure that it isn't about this issue described here: http://stackoverflow.com/questions/8564210/why-are-we-instal... ?

You never use tools like rbenv or rvm on production servers. They exist so that mac devs can be running the same versions of ruby found in the Linux distros.

Well, I use Debian for development and production, and I would never use Debian ruby packages on production. With the Debian packages, you have no idea what version you're getting. And then gem installs can only be done by the root user, not the deploy user. What a mess.

Godspeed Leader Nussbaum! I hope that your first action is to find a replacement for whoever was responsible for the debian-ruby disaster.

I haven't used Ruby much, but the Debian approach works well for me in Perl. I like that instead of pulling random packages off CPAN with no testing, I can depend on a Debian package of a Perl module, which is integration-tested with the rest of the distribution and release-managed, especially in terms of which other packages and versions it works with.

How do you ensure which versions of the packages that you receive?

It is nice to rely on system-packages, but if you depend on certain versions of certain packages you might see problems with that approach.

If you depend on certain versions of a package you have bigger problems.

Yeah, legacy systems, you are fortunate if you don't have to deal with these.

apt-get -s install ruby1.9.1-full. A simulation-only dry run that will show you exactly what is being installed.

I am pretty sure I have done gem installs as the current user with the Debian packages. It could be that they changed something recently though.

37signals is using rbenv in production, and I know of several other big companies that does as well, and I am feeling quite comfortable using it.

I would argue the opposite: you should always use rvm (or similar) in production. I've done this for many projects, it's great to have the same ruby version and patchset in development, CI, staging, and production. rvm is also well supported in capistrano and jenkins.

I'm not sure why most tutorials suggests installing RVM. You don't need rvm unless you are a running multiple rubies. You can install v1.9.3 from apt-get install ruby1.9.3. And a production server shouldn't run RVM. RVM just adds unnecessary complexity.

Reply on news.ycombinator.com