This morning I thought about Bundler for a long time. I ended up
writing a blog post on the subject. I realize some of my
assumptions about “why” may be somewhat off, but certainly they still
apply even if they are not the direct teleological causes.
On Sat, May 15, 2010 at 10:48 AM, Intransition [email protected]
wrote:
This morning I thought about Bundler for a long time. I ended up
writing a blog post on the subject. I realize some of my
assumptions about “why” may be somewhat off, but certainly they still
apply even if they are not the direct teleological causes.
‘Primary of these […] The rationalized benefit being that you need
never worry about remote services going down’
At most, this is a beneficial side effect.
‘As for the fear of “monkey releases”, i.e. new versions of a gem that
that might break an app, this is somewhat understandable but
redistributing every dependency with each app is shear overkill.’
Most developers use ~> for conservative gem dependencies with good
results.
You needn’t redistribute every dependency with each app. You do have
the option to conveniently package them all if you’re deploying to,
say, a shared host.
‘If you are that concerned a gem will break an application, one can
always specify exact requirements in the gemspec, and use the gem
method to nail the version down. That, in fact, is the whole point of
the gem method’
‘And the second, more significant issue that RubyGems, and hence
Bundler, cannot resolve being version conflicts. RubyGems blows-up
when it encounters a conflict. Bundler only mitigates this issue by
giving you a heads up before you ever run your tests.’
RubyGems resolves gem dependencies at runtime. If an incompatible
version is already activated, it raises an exception. This is a
perfectly cromulent way to handle version conflicts for most people,
most of the time.
Bundler globally resolves the graph of gem dependencies at boot time
instead of runtime. This handles the case where you use two libraries
which depend on a common third library, but with overlapping version
requirements. Resolving serially, at runtime, results in a version
conflict, but resolving globally picks a version of the common third
library that works for both.
‘This is the real heart of the matter, and it stems from the
fundamental lack of version support in Ruby itself.’
I don’t understand your conclusion.
jeremy
You’re not the only one, but I think we’re in the minority. gems have
been a mess for years, badly documented, and unintegrated with any
particular OS or distribution. Programmers that issue gems use habits
that make use of more mature packaging systems difficult. From a
sysadmin point-of-view, they make Ruby-heavy systems unmaintainable in
the long-term, as any global “gem install” is likely to break
applications.
At Bytemark, we’ve started to hack out a better packaging infrastructure
based on stodgy old .debs, and some automatic scripts to convert sets of
popular gems to work with lenny & lucid. Our automatically-managed
systems need one extra apt sources line; we excise explicit use of Gem
or ‘gem’ binaries where they’re installed, and we just “require” what’s
needed. It’s turning into packaging bliss.
That means you can only have one system-wide version of any library, and
that is just FINE thanks 
We think the useful Ruby libraries are
small in number, and the useful ones are proving themselves with stable
releases. We can live without those gems which change their APIs every
minor version - that kind of alpha code needs copying into your app, not
tied into a scissors-and-glue “packaging” system based on github
snapshots or other flaky URLs.
We’re in the middle of reinstalling our own apps and Ruby-heavy systems
without gems, and will share our work later in the year once we’ve
proved to ourselves it all works.
On May 15, 3:09 pm, Jeremy K. [email protected] wrote:
You needn’t redistribute every dependency with each app. You do have
the option to conveniently package them all if you’re deploying to,
say, a shared host.
Is that a common need? I doubt I’d use a host that make it necessary
for me to handle it that way.
library that works for both.
Ah, that’s interesting. I did not realize Bundler improves the
situation a bit by choosing a happy medium, if one exists. Now that i
know this, I would say it is the one truly significant feature that
Bundler provides. I would like to see RubyGems itself incorporate this
capability.
‘This is the real heart of the matter, and it stems from the
fundamental lack of version support in Ruby itself.’I don’t understand your conclusion.
Ultimately it boils down to the fact that we cannot use two versions
of the same library in a single process. Ruby could support this, and
thus remove the need for much of this additional work.
On May 15, 6:46 pm, Matthew B. [email protected] wrote:
popular gems to work with lenny & lucid. Our automatically-managed
systems need one extra apt sources line; we excise explicit use of Gem
or ‘gem’ binaries where they’re installed, and we just “require” what’s
needed. It’s turning into packaging bliss.
Sounds interesting. I’d like to know more. How does it compare to
GitHub - rtomayko/rpg: Fast ruby package management for unix for instance?
That means you can only have one system-wide version of any library, and
that is just FINE thanksWe think the useful Ruby libraries are
small in number, and the useful ones are proving themselves with stable
releases. We can live without those gems which change their APIs every
minor version - that kind of alpha code needs copying into your app, not
tied into a scissors-and-glue “packaging” system based on github
snapshots or other flaky URLs.
That reminds me of an old packaging system that came out just before
RubyGems. It was closely controlled to include only high quality
packages. Any one recall it’s name?
We’re in the middle of reinstalling our own apps and Ruby-heavy systems
without gems, and will share our work later in the year once we’ve
proved to ourselves it all works.
It will be interesting to see what you’ve come up with. Thanks.
On Monday, May 17, 2010 10:40:57 am Intransition wrote:
On May 15, 3:09 pm, Jeremy K. [email protected] wrote:
You needn’t redistribute every dependency with each app. You do have
the option to conveniently package them all if you’re deploying to,
say, a shared host.Is that a common need?
Yes.
I doubt I’d use a host that make it necessary
for me to handle it that way.
I usually wouldn’t either, but you can see the appeal of spending, say,
$5/mo
for a managed, shared host, instead of $20/mo for one you have to manage
yourself.
I mean, I like system administration, but your typical blogger doesn’t
want or
need to do that themselves.
There’s also Google App Engine. While we don’t currently have the latest
bundler working, we do effectively need it, and it means I get to start
hosting an app for free with a significant amount of bandwidth and CPU
before
I have to start paying.
library that works for both.
Ah, that’s interesting. I did not realize Bundler improves the
situation a bit by choosing a happy medium, if one exists. Now that i
know this, I would say it is the one truly significant feature that
Bundler provides. I would like to see RubyGems itself incorporate this
capability.
I like that it’s separate, and I also don’t see how it could
realistically be
imported into Rubygems itself, at least as it’s commonly used.
‘This is the real heart of the matter, and it stems from the
fundamental lack of version support in Ruby itself.’I don’t understand your conclusion.
Ultimately it boils down to the fact that we cannot use two versions
of the same library in a single process. Ruby could support this, and
thus remove the need for much of this additional work.
Maybe. Even in that case, though, I would still want a convenient way to
bundle gems, or to specify one gem depending on another, or to specify
my app
depending on multiple gems. A package manager is the natural result.
I do wish it was better integrated into the system package manager, but
I
don’t think replacing everything with debs is a solution, especially
seeing as
not everyone uses Debian or a Debian-derivative.
On May 17, 2010, at 10:48 AM, Intransition wrote:
That reminds me of an old packaging system that came out just before
RubyGems. It was closely controlled to include only high quality
packages. Any one recall it’s name?
I believe it was called RPA.
James Edward G. II