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

[Chad Fowler]

On Mar 18, 2004, at 7:41 AM, Gavin Sinclair wrote:

> 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?
>

Sorry, I meant $RUBY_GEMS.  This is a $PATH-like delimited list of 
directories that works like you would expect a search path to work.  
Whatever is first in the $RUBY_GEMS environment variable will be where 
new things are installed.  But, if you have system-wide gems, those 
would be picked up when they were not found in your personal 
directories.


>
>>> 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 almost suggested the same thing.  Opinions anyone else?

>
>>> 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
> before).
>

Do you mean you don't know how to motivate people to contribute more 
gems?

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

Austin and I did some Rublog/Ruwiki integration with eventual plans to 
create a bundled, integrated package.  Might still be worth checking 
out.

Chad