RubyForge website

Ruby
1

A lot of projects in RubyForge have no website, other than the
“Hopefully coming soon…” message. Might I suggest that the site
default to the RDoc of that gem (or gems)?

Advantages:

  • Every project has a site letting you know what it does (sometimes
    there is next to no info on the project page).
  • Encourages developers to keep the RDoc up to date
  • The most common site that projects do have is simply their RDoc. So,
    we’ve removed one step for all of those projects.

Disadvantages:

  • Requires a little processing on the rubyforge server (to extract the
    RDoc)
2

A lot of projects in RubyForge have no website, other than
the “Hopefully coming soon…” message. Might I suggest that
the site default to the RDoc of that gem (or gems)?

Yup, or have that in one of the tabs for each project.

Advantages:

  • Every project has a site letting you know what it does
    (sometimes there is next to no info on the project page).
  • Encourages developers to keep the RDoc up to date
  • The most common site that projects do have is simply their
    RDoc. So, we’ve removed one step for all of those projects.

Disadvantages:

  • Requires a little processing on the rubyforge server (to extract the
    RDoc)

Is there any security aspect to this - does running RDoc on a gem
require installing it or executing any of the code in the gem? I
suppose it could be done on a different machine and uploaded to
RubyForge, though…

Yours,

Tom

3
  • The most common site that projects do have is simply their
    RDoc. So, we’ve removed one step for all of those projects.

Disadvantages:

  • Requires a little processing on the rubyforge server (to extract the
    RDoc)

Is there any security aspect to this - does running RDoc on a gem
require installing it or executing any of the code in the gem? I
suppose it could be done on a different machine and uploaded to
RubyForge, though…

Don’t do this unless you either hard-code the RDoc template or limit it
to a pre-selected list. Using the options specified in the Gem
specification allows Gem authors to run arbitrary Ruby code on the
RubyForge server.

I’ve written about this several times on the RubyGems mailing list in
the last week or so. For those of you not subscribed to the RubyGems
mailing list, you can find the relevant posts at the following URLs:

http://rubyforge.org/pipermail/rubygems-developers/2007-January/002433.html
http://rubyforge.org/pipermail/rubygems-developers/2007-January/002454.html
http://rubyforge.org/pipermail/rubygems-developers/2007-January/002459.html
http://rubyforge.org/pipermail/rubygems-developers/2007-January/002466.html
http://rubyforge.org/pipermail/rubygems-developers/2007-January/002471.html

Fair warning: Each post is longer and more detailed than the previous
one, so do yourself a favor and grab a soda or beer before diving in.

PS. I have a mostly working patch for RubyGems that creates a protected
chroot() environment for generating documentation. Since this seems to
be a topic of interest I’ll get it clean enough to post for discussion.