[Rubygems-developers] $VERBOSE and error messages

[Gavin Sinclair]

On Sunday, April 18, 2004, 10:25:22 PM, Chad wrote:


> On 18/4/2004, at 12:58 AM, Gavin Sinclair wrote:

>>
>>
>> I just added (but didn't commit) this code to the option parser in 
>> bin/gem:
>>
>>       op.on('-v', '--verbose', "Give more verbose output in error 
>> conditions") {
>>         $VERBOSE = true
>>       }
>>

> If we set $VERBOSE to true, won't it potentially create a lot of other
> output that we don't want?  I generally like what you're doing here,
> but I don't think we should mix the two VERBOSEs.  There might be 
> something to be said for also showing ruby's VERBOSE output, but as an
> application user, I seldom want to see the details of what the 
> underlying VM or interpreter is doing when I turn on verbose mode.

Yeah, quite right.  Should it be $gem_verbose, or $GEM_VERBOSE, or
something like that?

>> And I have already added (and committed) this code to the "build" 
>> operation:
>>
>>   rescue Gem::Exception => err
>>     puts "Operation failed: #{err}"
>>     puts err.backtrace if $VERBOSE
>>   rescue => err
>>     puts "Unexpected error: #{err}"
>>     puts "Details:"
>>     puts err.backtrace
>>     exit!
>>

> This brings up a good point.  I think this is OK to add now (it matches
> similar things in the code), but I would like to generally see us pull
> all user interaction (like "puts", "print", and "get" in today's world)
> up into the level of the "gem" command.

Agreed.  This *is* the gem command :)  Although a line needs to be
drawn *inside* bin/gem and split some of it out to the library side.
That's basically the Facade code.  So I guess we're saying the same
thing :)

> A good example of why this is more than just an idealist desire is
> Curt's gem browser.

Yes, a good driver.

> As of now, he would have to do an ugly hack to do a remote install
> with dependencies, because that code (which I created) uses a "gets"
> from deep within the model to confirm that it's OK to install a
> dependency.  Curt would probably prefer a dialog box. I had a plan to
> fix it with a kind of resumable exception thingy, but I haven't had
> a lot of time in the past week.

Yes, I was giving it some thought as well, and came up with this idea
(pseudocode).

  installer.install(name, version, force, dir) do |feedback|
    if feedback.install_dependency?
      print "Do you approve the installation of #{feedback.dependency}?"
      answer = _get_response
      feedback.confirmation = (answer =~ /^y/i)
    elsif feedback.some_other_condition?
      # ...
    end
  end

I hadn't done anything other than think about it though.

>> Notice that a *gem*-related exception just gets a brief error message
>> by default, but an unexpected error (e.g. NameError) will get the full
>> gory details (needed for tracking down the cause).
>>
>> I like this approach, but would like to solicit comment.  In
>> particular, should we be using the existing variable $VERBOSE or not?
>>

> I think it's a great idea, but I don't like the use of $VERBOSE.  I may
> be wrong, though.

No, quite right; I'll do something else.

Just a quick thought: what about this?

  --no-verbose         # obvious
  --verbose 0          # ditto
  --verbose 1          # $GEM_VERBOSE = true
  --verbose            # ditto
  --verbose 2          # $GEM_VERBOSE = true and $VERBOSE = true

Seems OK to me, because you would rarely use anything other than
--verbose (or --no-verbose to override), but setting $VERBOSE is
available when you want it, and that's quite handy for debugging.

Gavin