# RubyGems issues

**URL:** <https://www.ruby-forum.com/t/rubygems-issues/75311>\
**Category:** Ruby\
**Created:** [March 1, 2006, 6:08pm UTC](https://www.ruby-forum.com/t/rubygems-issues/75311 "2006-03-01T18:08:43Z")\
**Posts on this page:** 5\
**Page:** 1

<div class="post-metadata">

**Author:** ![Bill\_Atkins](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/b/c4cdca/32.png) [@Bill\_Atkins](https://www.ruby-forum.com/u/Bill_Atkins)\
**Post date:** [March 1, 2006, 6:08pm UTC](https://www.ruby-forum.com/t/rubygems-issues/75311/1 "2006-03-01T18:08:43Z")

</div>

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?

- 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?

- 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.

- 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?

- 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?

- 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.

I don’t use gems that often, but whenever I do, I remember these  
problems and get deeply frustrated. If gems is going to be included  
in the next Ruby release, it can’t hurt to at least have some of these  
issues considered and either fixed or debunked.

- a crotchety old RPA-user

---

<div class="post-metadata">

**Author:** ![Bill\_Atkins](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/b/c4cdca/32.png) [@Bill\_Atkins](https://www.ruby-forum.com/u/Bill_Atkins)\
**Post date:** [March 1, 2006, 6:21pm UTC](https://www.ruby-forum.com/t/rubygems-issues/75311/2 "2006-03-01T18:21:04Z")

</div>

On Thu, Mar 02, 2006 at 02:08:37AM +0900, 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?

That is a bit weird.

} - 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?

There’s a flag you can give that will just automatically install all the  
dependencies.

} - 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.

If you don’t specify the -r then it searches locally first, but it will  
install from remote if it doesn’t find it.

} - 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?

The documentation need not be part of the bandwidth required if it can  
be  
generated locally. In general, bandwidth is more precious than CPU time.  
Also, you don’t have to have the docs generated at all, which saves time  
and disk space.

} - 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?  
}  
} - 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.

These are real issues.

} I don’t use gems that often, but whenever I do, I remember these  
} problems and get deeply frustrated. If gems is going to be included  
} in the next Ruby release, it can’t hurt to at least have some of these  
} issues considered and either fixed or debunked.

Eh, that’s nothing. I wound up writing a shell script over 100 lines  
long  
to get it to install itself and all subsequent gems in /usr/local. I’d  
really like that to be fixed.

} - a crotchety old RPA-user  
–Greg

---

<div class="post-metadata">

**Author:** ![Bill\_Atkins](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/b/c4cdca/32.png) [@Bill\_Atkins](https://www.ruby-forum.com/u/Bill_Atkins)\
**Post date:** [March 1, 2006, 8:13pm UTC](https://www.ruby-forum.com/t/rubygems-issues/75311/3 "2006-03-01T20:13:30Z")

</div>

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.

> - 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.

> - 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 W.

---

<div class="post-metadata">

**Author:** ![Bill\_Atkins](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/b/c4cdca/32.png) [@Bill\_Atkins](https://www.ruby-forum.com/u/Bill_Atkins)\
**Post date:** [March 1, 2006, 8:39pm UTC](https://www.ruby-forum.com/t/rubygems-issues/75311/4 "2006-03-01T20:39:13Z")

</div>

On Mar 1, 2006, at 1:33 PM, Bill Atkins wrote:

> > 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.

I would love this feature. HighLine prefers termios, but it has a  
fallback hand-rolled input method it will default to. Unfortunately,  
I can’t make termios a requirement because of Windows.

It would also be cool for projects that prefer FasterCSV, but that  
will settle for CSV.

James Edward G. II

---

<div class="post-metadata">

**Author:** ![Bill\_Atkins](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/b/c4cdca/32.png) [@Bill\_Atkins](https://www.ruby-forum.com/u/Bill_Atkins)\
**Post date:** [March 1, 2006, 8:34pm UTC](https://www.ruby-forum.com/t/rubygems-issues/75311/5 "2006-03-01T20:34:22Z")

</div>

Jim W. [removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid) 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 do i have to specify -r on the command line to build  
> > However, there are plans to unify the specification of gems so that 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.

> Better feedback during install, gotcha! Agreed.
> 
> – Jim W.

Thanks for responding!