From: Bill Atkins Date: 2006-03-02T04:33:38+09:00 Subject: Re: RubyGems issues Jim Weirich 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/.