[wildchild]

Wise decision. Ruby has it's own package system. I believe every developer using rvm/rbenv for managing ruby versions. Rails should be installed using rubygems. I always cry seeing pretty outdated rails packages in distributives. I don't care.

[inopinatus]

Unfortunately this leads to language binaries & libs being distributed by the developer with the application. Sysadmins then install the whole massive hairball in /opt as a single unit and never update it until the developer provides a point release. Which never happens because the dev team has been disbanded, they're all on new projects now.

If you don't think that's a problem in the real world, you ain't seen 95% of enterprise IT.

(This problem not confined to Ruby)

[hosh]

We're in the age of technologies like Chef, Puppet, and virtual machines. Said hairballs are described by code, and versionable.

And if that is still a problem for 95% of the enterprise IT, I guess that's why startup tend to kick their butts out in the frontiers.

[inopinatus]

I appreciate your butt-kicking energy! However, I must note: configuration idempotency tools that regard infrastructure as code are not new. I think you'll find that the inadequacy of cfengine, puppet & chef to the task is why they are not universally used. Devops is a very young discipline and these tools are the stepping stones toward a more coherent model of component deployment. I'm not saying they're crap, just that we can and will do better. Chef is probably the best effort so far, although I am unconvinced by the client/server variant.

In particular, none of them yet solve the problems of client application deployment. They are also implicated in the VM sprawl many cloud users experience.

Finally, they have convinced some developers that systems administration is something they can do themselves. Experience consistently proves this wrong; I've lost count of developers out of their depth, asking for rescue from suboptimal deployment decisions and needing rescuing. Either that or they discover a penchant for systems admin as well, and thus become devops people (this is what happened to me). I've seen the latter happen most often in the ISP world; perhaps network engineers have that mindset.

Personally I foresee a stronger role for packages as an output from continuous integration pipelines (another young discipline).

[hosh]

Ah, so if by client you mean end-user devices ... yeah. I am not sure Chef or Puppet solves it. On the other hand, my world has been focused on web and mobile apps, so end-user apps tend to use browsers that are already on the end-user device.

I'm not sure what you mean by clients though and how that relates to VM sprawl.

It's true that some developers are convinced that sys admin is something they can do themselves. However, it goes the other way around too, that sys admins think they know what is best for the app. It's better all around if devs actually gain an understanding at the issues with sys admin, and sys admins get some development skills.

As far as the server-side goes, once nice thing about using something like Chef or Puppet is that you can create a miniature version of the production environment on the developer's laptop. You won't run into the same kind of issues when you are scaling out, but you can at least make sure that you are running everything rather than always developing things in isolation.

[atsaloli]

Can you tell us more about this problem of client application deployment, please? I work with CFEngine quite a bit and it can deploy server and client components. What issues are you running into?

[ballard]

Yes. Maintaining a canonical set of ports for frequently changing language-managed packages is like getting into a phonebook reprinting business. It would be a far better use of precious volunteer time for any given language package to push OS specific changes to that upstream rather than grow downstream collections. The *BSD community could also learn something from the arch AUP as a way to end-users to roll their own packages to make it easier to contribute and reduce their own deployed systems' entropy ... because having a singular ports collection is like SVN or top-down planned economies... they are labor-intensive to support and their decision making is distantly divorced from the intended use-case. Different from AUP would be human-sensible configuration management that doesn't require manual intervention or too much tweaking for deploying 1k+ nodes.

[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.