[Rubygems-developers] GUI Interfacing with rubygems?

Chad Woolley thewoolleyman at gmail.com
Thu Dec 28 21:05:43 EST 2006

On 12/28/06, Eric Hodel <drbrain at segment7.net> wrote:
> On Dec 28, 2006, at 11:42, Chad Woolley wrote:
> > * There's no really cohesive API for RubyGems.  Whether you use the
> > command line or the api, you have to do parsing out text and acting on
> > it (parsing versions/platforms/etc).  If you want to use it
> > programatically, you have to hit a few classes.
> I've done a ton of work on this for the 0.9.1 release.  Methods have
> shifted around and the RemoteInstaller has been drastically cut down
> in capabilities.  Those capabilities have all moved to other
> locations where they make more sense.  (I did all this to perform
> automatic sandbox gem installs for my secret project.)

Great news.  Too bad I'll still have to support the old release for a while :)

> > I've got proxies for GemRunner and SourceIndex, and some mixin
> > hacks for StreamUI so I can intercept stdin and stdout.
> Why do you need a proxy for SourceIndex?  Its pretty much self-
> contained.

Because I'm using Rspec and mock-intensive Behavior-Driven Development
approach.  I follow the rule of thumb to "Only Mock Types You Own"
[1].  In other words, wrap any third-party code you interface with in
a proxy interface, and only proxy the methods you need to use, then
test the heck out of it with "Enemy Unit Tests" [2].  That way, if the
behavior of the third party code changes (which it very might well
have with your refactorings!), you know exactly what isn't behaving
the way it used to.

These ideas are from:

1. "Mock Roles, Not Objects" - http://www.jmock.org/oopsla2004.pdf
2. "Enemy Unit Tests" - the GroboUtils project -

> > * Specifying platforms for multiplatform gems.  Currently, there is no
> > way to specify platform via a command line option or API.  It's
> > hardcoded to always present a list if theres a binary (non-ruby) gem,
> > and ask for the user to make a choice via stdin (which I had to work
> > around with the mixin hacks for StreamUI).  There is talk of changing
> > this, but the developers want to gather data on what platforms people
> > use first.  I'd really like to just get a command line option for
> > platform added ASAP - hint hint :)
> This is on the table for 0.9.2.  It was too big of a change to make
> for 0.9.1.  Chad and Jim have a side project that'll get us
> information to help with this too.

Yep, they mentioned Tattle in the earlier thread where I asked.  I
just hope that the Tattle data gathering process doesn't unnecessarily
delay the addition of the --platform option.

Actually, embedding hooks/autoinstall for Tattle in tools like
GemInstaller, RubySlippers, and Eloy's project seems like a great way
to get Tattle in widespread use more quickly.

> > *  Dealing with sudo.  This is currently my only remaining blocker for
> > releasing geminstaller.  Must people have rubygems installed as root,
> > so commands that modify the gem repository must be run via sudo.  I
> > would like to have a command line option --sudo which uses sudo to run
> > gems, but this doesn't work if you are calling into the API
> > programatically.  On the other hand, I could use the command line
> > interface, but this is also tricky in ruby, to properly deal with
> > stderr, stdin, and timeouts if the gem command is expecting different
> > stdin than you think it is.
> 0.9.1 will not download gems from the server if everything is up-to-
> date.  This will give fewer instances where gems will need to read
> from the console (of course, there's always the platform problem).
> (In 0.9.2 I'd like to pull most of RemoteInstaller's functionality
> into a DependencyInstaller which will make network-free installs much
> cleaner.)
> > Also, if you use the command line, you have to parse errors out of
> > stdout/stderr as opposed to just catching exceptions.  If anyone
> > has ideas here, please let me know.
> 0.9.1 raises many, many more exceptions (and useful ones, at that)
> and outputs to stdout much less (especially for extension building).

Yes, but you still need sudo support if a gem actually needs to be
installed, and AFAIK this means invoking the command line tool

Also, one (maybe bad) suggestion would be to eliminate the use of
stderr altogether, since it's relatively difficult to capture stderr
output under Ruby in a cross-platform (works on windows) way.
IO.popen doesn't allow you to capture stderr, and output = `gem
#{args_string} 2>&1` is the only other way that I know works on
windows, but this approach makes it difficult to handle stdin.

To see my as-yet-unsuccessful attempts to solve this issue, look at
the history of gem_command_line_proxy.rb and
gem_command_line_proxy_spec.rb in the geminstaller source.

> Eric Hodel - drbrain at segment7.net - http://blog.segment7.net

Thanks for the responses!

-- Chad W.

More information about the Rubygems-developers mailing list