[Rubygems-developers] Issues, some Windows related:

Jim Weirich jim at weirichhouse.org
Mon Oct 25 08:19:01 EDT 2004

Thanks Austin, for the fantastic feedback.
I'll respond to a few points.

On Saturday 23 October 2004 09:43 am, Austin Ziegler wrote:
> 1. Curses. Can we look at adding an ability to check for specific
>    prerequisites that are NOT gems? [...] 
>    Thus, when I install 'diakonos', I  get:
>       C:\home\Projects\[releases]\diff-lcs> gem install diakonos
[... some output elided ...]
>       File not found:
>    [Note: I don't know what file it couldn't find.]

Actually, this error message isn't related to the use of curses.  AFAICT, 
diakonos is incorrectly packaged.  The gem spec lists "bin/diakonos' as an 
installable executable, but there is no bin directory in the gem package.  I 
suspect that is the reason for the (rather unhelpful) "File not found" 
message.  I looked around for the code that produces the error (so I can at 
least add the file name to the message), but wasn't able to find it.  I'll 
look deeper later.

But addressing your question of the ability to check for non-gem dependencies, 
I'm not sure how to do that in a non-platform specific way.  Any suggestions?

> 2. Spelling. Uninstalling 'diakonos' gives me this message:

Fixed in CVS.  Thanks.

> 3. Compiles. [... on Windows ...]

Actually, I have a need to setup a ruby compile environment on my windows box 
at work.  I'm hoping someone can help me.  I am completely at a loss on 
compiling C extension on that platform.  Anybody got pointers?

> 4. Exception messages. Installing 'builder' but I typed:
> [... monstrous backtrace elided ...]
>  I haven't
>  done a lot of this myself in my command-line utilities, but we
>  should really TRAP certain exceptions or signals and handle them
>  cleaner. The default Ruby mechanism is nice for developers, but
>  is completely inappropriate for end-users, rather like the
>  default Java mechanism was years ago.

Currently gems traps all StandardError exceptions and gives a nice error 
message.  If you want a backtrace, you have to provide the --backtrace 

However, in your case, a control-C produces an Interrupt exception which does 
not derive from StandardError.  That raises the question: Should we trap all 
Exceptions rather than just StandardErrors.  If we change to trap Exceptions, 
are there certain Exceptions we should not handle?  (E.g. SystemExit is an 
example ... what should we do in case of SystemExit).

Also, a note to developers:  The ability of Gems to handle exceptions 
gracefully depends on the code not /NOT/ handling exceptions explicitly, but 
propagating exception up to the command handling level where they are handled 
consistently.  I went through the code base once and made this consistent, 
but lately I found at least one location where a command is trapping an 
exception and printing a backtrace without checking the backtrace flag. Just 
a word of warning.

Thanks again to Austin for the good feedback.

More information about the Rubygems-developers mailing list