[Rubygems-developers] Binary distribution
chad at chadfowler.com
Wed Dec 3 17:31:09 EST 2003
On Wed, 3 Dec 2003, Jim Weirich wrote:
# Chad Fowler wrote:
# > Any other issues anyone can think of in distributing binaries?
# I just want to say that I think that supporting binary gems for the
# Win32 platform is important. I suspect that most Nubies will be windows
# folks and their expectations are the most stringent of the platforms.
# If a Linux guy needs to twiddle the download a bit before it works, he
# half way expects that. But I would like to see windows easily supported.
Totally agreed. In fact, even when Rich and I were getting "cold feet"
for this idea, we acknowledged the need to support Windows users. They
just don't generally even have a compiler.
# That being said, my main platform is Linux, and I wonder how I am going
# to support binary gems for platforms I don't have.
I've had an abstract thought for some time that might be appropriate to
bring up now. RubyGems can be served, as you know, very easily via
webrick and Apache. And, of course, we can handle a configurable list of
"sources" from which to attain gems. The sources list itself is a gem, so
it's easy to "upgrade".
Since creating a gem server can be as simple as firing up a single command
on your machine (powered by webrick), it's possible to view this whole
system as a kind of limited P2P. I think this provides a framework for
keeping "official" gem servers up to date with each other (e.g.
gems.rubyforge.org, gems.rubygarden.org, gems.ruby-lang.org), with this
framework making use of existing rubygems technology.
What would be really nice is to create some kind of system that would let
trusted end users also participate in the scenario. You (Jim) don't have
a Windows box to compile on, but I do. And so do a bunch of other Ruby
users. How might we make it easy for people to help? "signed" gems and
trusted sources? I don't know really.
# Regarding source gems ... one of the current problems with source gems
# (with C/C++ code) is that they can be built in different ways (eg.
# setup.rb vs extconf.rb). Fundamentally, this is a build problem and
# perhaps rake is a better tool than rubygems to attack this problem. I
# would appreciate feedback in this area as well.
I agree re: rake. But I also like the idea of source gems holding the
source plus metadata (and the Rakefile). I personally dont' see any
reason we wouldn't tightly integrate Rake and Gems for source building.
Source building sounds like a very complicated thing to support in a
More information about the Rubygems-developers