Re: Core support for Gems, and namespace

On Wed, 28 Jul 2004, Austin Ziegler wrote:

> There isn't one -- yet. An alternative solution is also being worked
> on. It's called "RPA", and is intended to be the Debian or ports of
> Ruby. I'm not sold on that one, either, because it's not a single
> installation mechanism that developers can use, but more of a
> process that also has an installation mechanism. The packagers
> aren't necessarily the developers.

Given how well both FreeBSD and Gentoo has done with this, I have high 
hopes for it.  I'll be supporting both, also, until some community 
standard develops.

I'll check out your install.rb.

> Much of this is discussed far more often and in far greater depth on
> ruby-talk and the RubyGems lists (and I'm not on the latter).

I know it (along with documentation "standards") have been discussed at 
length, but I hadn't been able to find a recent discussion, and I couldn't 
find documentation anywhere that implied that the problem was solved or 
anything.

[...]

> You must specify the *gem* name rather than the default load library 
> (e.g., diff-lcs rather than diff/lcs) because the gem name is all that 
> RubyGems knows a library by. This is one of the things that I don't like 
> about RubyGems and think that RPA will possibly handle better -- but I'm 
> not sure.

Yeah, I definitely don't like that.  Like I mentioned in my previous 
email, I think in terms of object space anyway -- I want to use 
Module::Class, so remembering that that's in the 'module/class' file is 
already annoying, but to have to remember that it's instead in 
'module-class' is, um, less than exciting.  I do hope that Ruby eventually 
acquires the ability to load modules by Object space rather than file 
name.

> Okay, who is going to impose those standards? Who is going to come
> up with them in the first place? Where does something like
> progressbar.rb fit (it's a textual progressbar)? I don't want to go
> the direction of Java domain-namespaces (e.g.,
> celsoft.com/interface), and I don't want them unnecessarily deep.
> (ui/text/progressbar => UI::Text::Progressbar). Perl's require
> equivalent doesn't use filenames, but namespaces. Thus, you can only
> ever HAVE one item that provides Text::Format. Ruby, however, could
> have text/format/austin.rb and text/format/joe.rb which both provide
> competing implementations of Text::Format. Not nice, for certain,
> but certainly feasible.

I definitely prefer perl's model where you can't have different objects 
providing the same object space, since it's incredibly unlikely that the 
two objects would have the same duck type and thus would be quite 
confusing.

As to who imposes the standards, "the community" would be the obvious 
answer, but that's relatively information-free at this point.  One of the 
reasons I brought it up in this thread, though, is that the topics of name 
space and packaging are closely related, and certainly in the perl world 
the packaging community are the ones who attempt to enforce accepted 
namespace standards.  If we can establish a packaging community with ruby, 
then that community would also, I expect, be de facto in charge of name 
space issues.

> It's been a while since I've done any serious Perl programming, as
> well, but I don't think that modules/packages are open in Perl the
> way that they are in Ruby. Thus, we'll have ext/numeric/format.rb
> (from the extensions project) which actually modifies the Numeric
> class. The namespace problem in Ruby is completely different than
> the namespace problem in any other language that I know, and is
> usually focussed on imported method names more than library
> collisions.

Perl actually does have the same abilities.  I can modify a package in an 
unrelated file.  It definitely doesn't focus on that as much, though, and 
it's definitely rare for one person to ship a library that modifies 
someone else's library.

I agree that this is a thorny problem, and I don't know how it should be 
solved.  I do think it would be worth looking for a solution, though. :)

> Unless, of course, you get caught in CPAN upgrade hell. I have had
> this happen to me. RubyGems is trying to avoid this. It's the one
> place that I can see the utility of the versioning scheme (it allows
> a library that requires another library to depend on a specific
> version and with the right gemspec, that version will be installed
> without affecting the general case). RPA will be doing the same
> thing in concept.

Heh, you find me a packaging system that maintains the packages that 
are the heart of the packaging system, and I'll find you a packaging 
system that can end up in upgrade hell.  I've generally found cpan to be 
pretty easy.

> *shrug* Perldoc sucks as a format. The tools around perldoc are
> pretty cool.

I'm not in a position to disagree with you on that, but I do know that the 
format doesn't get in my way, generally, and it's quite easy to use.

> ... ri is the preferred way for handling this stuff at least right now.

Okay, that clears that up.

> As far as manpage/help stuff is concerned, there are two ideal choices 
> for option handling and parsing, both of which will give you awesome 
> help output. The first is optparse and the other is a port of a Perl 
> library (can't remember the name, offhand) by GGaramuno.

It's not the handling/parsing problem I was pointing to -- it's the 
ability to easily integrate my embedded documentation with that parsing 
system:

$opt_result = GetOptions (
     "help" => \$help,
);

if (! $opt_result) {
     pod2usage('-exitval' => 1, '-verbose' => 0);
     exit(1);
}

if ($help) {
     pod2usage('-exitval' => 1, '-verbose' => 2);
     exit;
}

I just write my documentation normally, and I can easily produce a small 
usage statement or a full man page, depending on whether the options were 
invalid or whether they specifically asked for the help system.  The 
options parsing is easy in ruby (using 'getoptlong'), but the rest...?

> rdoc and ri are now both part of the Ruby sources. Most of this
> information has been communicated both on ruby-core and on ruby-talk
> in the last six months.

Huh.  I'm running 1.8.0 and 1.8.2, depending on the machine; any machines 
which have either rdoc or ri executables were installed manually by me, so 
I assumed they were not integrated at all.  Oh well.  I'll try to pay 
closer attention, but newbies will definitely be having the same problems. 
(I probably still qualify as a newbie in plenty of ways).

> The thing is, the configure/make/make install cycle persists because
> it works.

Maybe, but it is seldom necessary for interpreted language libraries, and 
to the greatest extent possible it should be automated.  I _love_ not 
having to go through it.

-- 
A diplomat is a man who can convince his wife she'd look stout in a fur
coat.
---------------------------------------------------------------------
Luke Kanies | http://abstractive.org | http://reductiveconsulting.com