On Mar 17, 2004, at 11:09 PM, Gavin Sinclair wrote:
> On Thursday, March 18, 2004, 1:50:19 PM, Chad wrote:
>>>> On Mar 17, 2004, at 9:42 PM, Gavin Sinclair wrote:
>>>> One open issue with RubyGems is handling applications and not just
>>> libraries. Libraries are "easy" in the RG model because RG mangles
>>> Ruby's $LOAD_PATH. That's not so easy with applications.
>>>>>> There are two options as I see it. [...]
>>> For what it works, I've been thinking about option 2. I don't think
>> symbolic links is an option.
>> s/it works/it's worth/ :)
>
I need a vacation. I was falling asleep as I wrote this :)
> Is that because of platform issues? If so, fair enough.
Right. Sorry, I forgot to explain that.
>>> I know that Matz (from RubyConf 2001) was very interested in being
>> able to distribute a single-file Ruby application. To me, gem --run
>> can fill that need, though the files will end up being extracted. As
>> long as it's transparent, it shouldn't matter. You could even do:
>>> gem --run mygem-0.1.1.gem
>>> ...and it could extract the gem to a personal directory if it's not
>> already installed (either globally or locally) and run transparently.
>> This wouldn't prevent a "single-file Ruby application" from failing
> because a required library was not installed. I wonder what Matz had
> in mind.
>
Matz wanted it to be easy for people to download a file and "run" it.
He was envisioning something akin to "java -jar blah.jar", if you're at
all familiar with Java. The problem with us taking the same approach
Java did (actually leave the code in the gem file and loading it from
there) is that we wouldn't be able to easily--at all--do that with
binary extensions.
>> That's kind of appealing.
>> Novel, but not that appealing to me. I've never used a "personal"
> gems directory, but I guess that's important on a multi-user machine.
>
I guess I didn't mean that having a personal gem directory was
appealing so much as the ability to automatically run an application
without installing it. Or, even after having installed an application,
gem --run would give you a symbolic way to reference and run it. It's
kind of reminiscent of MacOSX's Blah.app structure. In the Finder,
"TextEdit" looks like a simple single-file application that can be run.
If you go into the Applications directory with a shell, you'll find
that "TextEdit" is really a directory called "TextEdit.app", with
subdirectories containing executables, help files, and metadata. You
can even find (and modify, I think) the piece of metadata that
specifies which executable to run when a user runs the symbolic
"TextEdit" application.
So, this is what I think is appealing. Not the implementation, but the
idea of being able to easily "run" an otherwise jumbled and loose
collection of files and have it mean something.
> What about:
>> gem -i ruby-doom --system # I prefer this as default.
> gem -i ruby-doom --user # Use $HOME/.gems or something.
>> Then require_gem should search both places. Of course, then the
> "list" and "search" operations need to take it into account. So the
> following permutations are possible:
>> gem --list --user # Implies --local
> gem --list --system # Implies --local
> gem --list --local # Lists user and system packages
> gem --list --remote # Lists remote packages
> gem --list # Lists local and remote packages
>> (This assumes the interface I wrote about recently.)
>> Modifying all the operations to know about --user and --system might
> be a fair bit of work, but I think it's very worthwhile.
>
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?
> 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.
>>> 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?
> So what about man pages? Same thing?
>> gem --man rake
>> I kinda like this as well:
>> gem --readme rake
>> This locates Rake's README (using a RubyGems convention and/or
> metadata) and pushes it through $PAGER (or in the case of Windows,
> opens it in Notepad or something).
>> That would hopefully encourage people to create useful README files and
> mean there's no need for man pages. You'd lose some formatting, but
> that's too bad. When an all-powerful gem browser emerges, it could
> run RDoc on the README to regain some formatting.
>> 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.
> Cheers,
> Gavin
>> 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.
> 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.