[whalesalad]

Yep. I don't know why anyone would want to install something like Rails, Django etc... via their distribution or OS's built-in package management system. I think it's silly actually.

Ruby has rubygems, Python has pip, Perl has cpan...

[tedunangst]

As somebody who occasionally uses software, besides just developing it, learning the command syntax and idiosyncrasies of a half dozen package systems is a pain in the butt. I want to type "pkg_add things I want" and be done with it.

[chimeracoder]

Not to mention that package management isn't a problem that should be solved at every single level possible - package management for the OS, package management for developing in $LANGUAGE, package management for extensions of $PROGRAM written in $LANGUAGE, etc....

Aside from the fact that that's redundant, it's highly error-prone.

[hosh]

As a long time Rails dev, I never trust the package maintainer's OS packages for Rails. I need specific versions of Rails and gems, often times specific git commits.

In places where the IT staff insists on making sure this isn't "redundant", they usually use something like fpm to create a deb or an rpm out of the gem specified by Gemfile. Which you then have to drop into a custom deb/rpm repository. On top of that, the ops staff don't know how to do that properly, so they end up with a bunch of testing and development dependencies that the Rails application doesn't need.

... or, you have the deploy process call, "bundle install"

The redundancy is in the OS packages, not in application dependencies. So it is actually better to automate such with something like Chef and Puppet. From there, I can define exactly what the application needs from the OS.

I have seen this play out in a lot of ways, devs vs. sys admin. In the past, sys admins "win" since compute resources were still scarce. We're in the age of virtual machines now and configuration automation. Applications get their own VMs, sometimes in multiple nodes. We don't have Unix high priests guarding the altar with SSH keys, hand-deploying things in secret early-morning ceremonies. We have automation to deploy for us, which means we want to make it easier for the automation to deploy, not necessarily for someone to shell in and maneuver around with hand installations.

Things being application-centric, the "right" thing is to conform to the requirements of the dev team's app, not the other way around.

[igravious]

Therefore 'pkg_add' needs to be able to hook into 'gem install' and 'gem list' and save you (and me) the bother. And this needs to be solved for apt and yum and homebrew and so on as well. I don't know, something needs to be done definitely.

[wmoxam]

It makes sense from the perspective of it being a dependency of some end user software such as Typo or Redmine

[dlisboa]

I've been messing around with FreeBSD for a few days and it has RubyGems set up very conveniently. Root installed packages (like the ones from ports) would already be attended through the root installed RubyGem.

Aside from OpenBSD which has their security procedures for installed software it doesn't seem like any ports distro really need to have copies of gems in their package tree if the RubyGems package is set up correctly. They could delegate that function to RubyGems, it'd be transparent to the user.

Some package managers go down a more drastic route and simply tell the user to install the dependency through the correct package manager (Homebrew does that with Node, top of my mind). Users can still do it locally with rbenv/rvm/chruby if they want, it doesn't change much.

The bigger I'd think is that they don't want to rely on external package managers for the stability of their system. Which is a very valid reason, if RubyGems is out you can't install certain ports. Or worse, the gems aren't safe. The system is then self-contained and tested, proven to work with the provided copies of gems.

But as a simple dependency resolution perspective I don't see it being the case.

[hosh]

I can tell you that deploying a Rails app needs to come from using rubygem and bundler, never the OS's package management.

As for security concerns: you can and should vet gems, but it won't matter if the application itself has vulnerabilities.

We don't have very many Rails app written as a packaged system for deployment. The kind you see are often SAAS apps or something to interact with people internally. They are often bespoke and written for specific needs.

[csense]

> never the OS's package management

Non-OS installation is a huge barrier to new users of a Ruby application. I installed Gitlab recently. Take a look at the length of the installation guide [1]. There are seven numbered steps, some of which involve multiple commands.

Upgrading from 4.0 to 4.1 was about the same complexity.

Thanks to the thoroughness of its author, the guide largely worked as advertised. But being able to install and upgrade with apt-get would have saved me hours.

[1] https://github.com/gitlabhq/gitlabhq/blob/stable/doc/install...

[hosh]

It is the case for now, but won't be much for longer. I expect application developers to start versioning Vagrantfile, Berkfile, etc. so that someone can bring up at least dev versions of apps.