[Rubygems-developers] Thoughts on handling bin and man files

Gavin Sinclair gsinclair at soyabean.com.au
Thu Mar 18 23:41:19 EST 2004

On Thursday, March 18, 2004, 11:11:51 PM, Chad wrote:

> [...] It's kind of reminiscent of MacOSX's Blah.app structure.  [...]

It's good to hear about "other approaches".  I think the traditional
Unix structure has outgrown its appeal.  Rubyx is taking a nice
approach (similar to "stow", I think).  OSX is obviously being a bit
clever too.  I hope it works.  In the meantime, at least it shakes
things up a bit and forces us to think differently (tm).

>> What about: [--system and --user example]

> We have a --dir switch right now, along with the $GEM_PATH environment
> variable.  I'm not sure whether --user and --system are needed in that
> case.  It might be better to let people manage what that would mean to
> them separately?

I really think it's worthwhile.  It takes away the hassle of managing
the target directory for 99% of cases.  That's gotta be worth
something.  It's the oldest trick in the unix book (/etc/profile vs
~/.profile, etc.).

If I were running on an enterprise Unix system and could only do
things locally, I'd be annoyed at having to specify the directory all
the time.  Sure, you can write an alias, but it's still a hassle.

It's OK for people who have installed Ruby in their home directory,
though, because RubyGems will use that location by default.

The main thing is that there can be a system-installed Ruby, and 100
users on the system who all want to install gems but can't unless they
do it locally.  If they set $GEM_PATH, won't the centrally-installed
gems be inaccessible to them?

>> BTW, "running" a gem file as you suggest doesn't appeal to me because
>> I don't know whether the installation of the gem will be temporary or
>> permanent.  It sounds temporary (since you're not actually asking gem
>> to install it), but would you *really* uninstall it after running?

> We might want to forget about my potentially very flawed 
> one-man-email-brainstorming session.  Is it "running" the gem that 
> isn't appealing to you or the implementation I suggested?  It sounds
> like it's my suggested implementation that you don't like.  I think the
> simple solution is to decide that you have to install a gem before you
> can "run" it.  I think it's a decent compromise.  Perhaps, then the 
> following:

> gem --run mygem-0.1.1.gem

> ...would first ask you if you would like to invoke the installer. If
> you say "no", you can't run the gem.  If you say "yes", it installs and
> then runs it.

Yeah, that sounds really good.  The brainstorm bore fruit after all.

>>> Of course, we would soon run into the problem that some "applications"
>>> come with two or more executables that you might run.  Take RubyGems
>>> for example. :) (gem and gem_server)
>> My take on that:
>>   gem --run rubygems               # Default app 'gem'.
>>   gem --run rubygems/gem           # Make it explicit.
>>   gem --run rubygems/gem_server    # Run the server.

> Seems reasonable, though the "/" makes me think we're pointing to a 
> file, which I don't think we would be in this case.  It would only be
> symbolic, unless we were to specify a "binpath" in the gem or 
> something.  In that case, you would have a default app "gem --run 
> rubygems" which would be run if you specify nothing but the gem name
> and then any gemname/otherprogram calls would get translated into 
> #{gemdir}/#{gembindir}/otherprogramname.  Is this what you were 
> thinking?

Precisely.  We could use ':' instead of '/' perhaps, to make it look
less literal and more logical.  For example:

  gem --run rubygems:gem_server

>> I certainly like the idea of a very powerful 'gem' frontend, don't I?
>> :)

> hehe.  I'm starting to think we should somehow segment it.

I wouldn't bother.  It's nice to know exactly which command to run :)

>> P.S. Nice to see code being written, RubyGems being released, and
>> ideas being discussed.  Progress by small steps pays off in the end.

> Yes.  Though, I'd like to see us make some big ones.

The availability of several gems for remote installation and the fact
that it just works is a big step, IMO.  We need to motivate people to
contribute more gems.  I haven't bothered, so I'm a good target.  To
be honest, I'm not really sure how (to contribute; I've done build

>> P.P.S. My main project at the moment (not that I have time,
>> unfortunately) is "RDocWeb", which creates pages exactly like
>> http://ruby-doc.org/stdlib, but in a generalised sense (i.e.
>> containing whatever packages you want).  When that's done, a program
>> could easily generate such a page for all of your installed gems.

> Have you played with Rublog much?  It might be conceptually very 
> similar (in its guts) to what you want to do.  At RubyConf, I wrote a
> Rublog convertor that syndicated a gem repository.

> Mauricio Fernandez ("batsman" on irc) has a tool called RDocSite which
> may also be related.

Thanks for the tips.  I've certainly looked at Rublog, and would use
it but I demand blog/wiki integration.  I hadn't heard of RDocSite,
but it sounds good.


More information about the Rubygems-developers mailing list