Jim Weirich <jim / weirichhouse.org> writes:

> Bill Atkins wrote:
>> Here are some issues I've noticed with RubyGems' user interface:
>> 
>>    - Why do I have to confirm each _required_ dependency?  What chance
>>      is there of leaving off a required dependency and still having a
>>      functioning install?
>
> Quite good if you've installed some software as non-gems.  That being 
> said, it is probably an edge case and you make a good point.

Maybe there could be a distinction between required dependencies and
suggested packages, i.e. dependencies would be absolutely necessary
for a gem to function but suggested packages can be installed or not,
at the user's discretion, without affecting the package's basic
functionality; suggested packages woudl then be treated as
"required dependencies" currently are.

>>    - Why does each confirmation happen individually?  It would make
>>      sense to confirm or reject _all_ required dependencies and thus
>>      abort the install, but I can't see any reason for the current way
>>      of doing things.  At the very least, why can't it find all the
>>      dependencies for the current package so that I can hit 'Y'
>>      repeatedly, instead of waiting a second or two for it to find the
>>      next dependency?
>
> Good point.
>
>>    - Why do i have to specify -r on the command line to build
>>      remotely?  I understand that local gem installations are possible
>>      (and maybe even common), but wouldn't it make sense for gem to
>>      assume that "gem install rails" is a remote install and "gem
>>      install rails.gem" is a local install?  In this case it wouldn't
>>      have to bother with this "attempting local installation"
>>      business.
>
> The -r is not required for remote installs, its just that it checks 
> locally now.
>
> However, there are plans to unify the specification of gems so that the 
> local/remote, version-requirements, and platform and all be specified in 
> a URL like manner (rather than as options on the command line).
>
> And I agree, the announcement that it couldn't find a local gem is 
> annoying, since the trend is that most installs are remote.
>
>>    - Why on earth, on earth, on earth is the package's documentation
>>      built locally?  It is by far the lengthiest part of the install,
>>      and I can see no good reason why this couldn't be done at gem
>>      build-time.  Am I missing something here?  How could the
>>      documentation differ from one machine to the next such that this
>>      approach would make sense?
>
> (1) Bandwidth as someone else has mentioned, (2) the ability to apply 
> different RDoc templates (my local docs all use the same template, no 
> matter what the software author used).  And you don't need to build the 
> rdocs if you don't want to.

Bandwidth usage is a good point that didn't even occur to me.  Is it
reasonable, then, to require user confirmation before installing docs,
and maybe pointing out that it could take a while?  I generally use
online documentation for libraries anyway, even if the documentation
happens to be installed somewhere on my hard drive.  I'm not sure if
this is a common way of doing things.  In any case, I'll use the
--no-rdoc flag in the future.

>>    - When there are warnings in the documentation building, why do
>>      these appear last, making it seem that there were problems in
>>      installing the gem itself?
>
> Agreed, confusing.  The whole local/remote unification thing will 
> probably address this.
>
>>    - Why so little output while installing?  Can't i at least pass a
>>      -v flag to get a better indication of what's actually happening?
>>      It would certainly make gem installs seem more responsive.
>
> Better feedback during install, gotcha!  Agreed.
>
> -- Jim Weirich

Thanks for responding!

>
> -- 
> Posted via http://www.ruby-forum.com/.