I was just drooling in anticipation for pickaxe 2 and looking through
the table of contents on the pragprog web site. I know this is
probably asking too much considering its recent release, but rpa-base
wasn't too far behind ruby-gems in being released, and I believe it is
definitely a worthy contender in the ruby package management arena. I
was disappointed to see that it wasn't included in the book, although
a whole chapter was devoted to ruby-gems.
Carl
I think the fundamental difference is that RubyGems requires
developers to package their own software whereas RPA is meant to be a
repository with a central team doing the packaging. Most of the
RubyGems content in the pickaxe is about how to create gems.
Ultimately, if gems become ubiquitous, it makes the RPA team's
(Mauricio, that is) job easier, because some thought will have to be
put into how to make software distributable in this kind of way[1]. I
see it as a win for everyone.
Chad (who wrote the rubygems chapter for pickaxe2)
[1] For an example, check
http://halostatue.ca/blog/index.cgi/Tech/Ruby/Ruwiki/Deployment.20040902.md
On Fri, 3 Sep 2004 07:32:05 +0900, Carl Youngblood <carl.youngblood@gmail.com> wrote:
I was just drooling in anticipation for pickaxe 2 and looking through
the table of contents on the pragprog web site. I know this is
probably asking too much considering its recent release, but rpa-base
wasn't too far behind ruby-gems in being released, and I believe it is
definitely a worthy contender in the ruby package management arena. I
was disappointed to see that it wasn't included in the book, although
a whole chapter was devoted to ruby-gems.
The Gems folks had done a good job of getting the word out, and I had enough lead time to work with them to add the material to the book. (In fact Chad wrote the chapter). rpa-base was below my radar during that period, and by the time I saw the announcement the book was well into final preparation. I added a quick reference and a paragraph in the resources section at the back, but there was no way to add a chapter and still get the book in on time. Had the rpa folks appraoched me suggesting a chapter, I'd have been very happy to include it.
That's the problem with books--even with a fairly agile publishing system such as ours, there are still deadlines and cutoff dates.
Rest assured that the chapter wasn't omitted for any reason that there not being any content there in time 
Cheers
Dave
On Sep 2, 2004, at 17:32, Carl Youngblood wrote:
I was just drooling in anticipation for pickaxe 2 and looking through
the table of contents on the pragprog web site. I know this is
probably asking too much considering its recent release, but rpa-base
wasn't too far behind ruby-gems in being released, and I believe it is
definitely a worthy contender in the ruby package management arena. I
was disappointed to see that it wasn't included in the book, although
a whole chapter was devoted to ruby-gems.
I'm sorry to have to tell you that there's no conspiracy theory behind
all this
Dave just didn't hear about RPA/rpa-base until it was too late... but
he added a short reference to RPA in the resource section.
At any rate, as Chad said, since RPA will be packaging itself instead of
asking the developers to adopt rpa-base, there's little (no) need for
an explanation of rpa-base's specifics in Pickaxe 2. rpa-base is still
open to modifications that could make such a chapter obsolete anyway.
I'd have liked a chapter on good practices, which would benefit all
repackagers -- making not only RPA's, but also FreeBSD's, Debian's,
etc job easier. I actually consider this *much* more important than a
detailed explanation of how to use RubyGems or rpa-base: good practices
are more stable than packaging technology, esp. in the initial stages.
Looking at the TOC of Pickaxe 2ed, it seems that chapter is very much
focused on RubyGems; I'd have preferred a general overview, followed by
an explanation of Aoki's setup.rb and then some short notes about how to
use RubyGems and most importantly where to find up-to-date documentation.
IMHO it makes little sense to give too many details since the specifics
are still subject to frequent changes. For instance, if that chapter
mentioned something about require_gem vs. stubs, it'd be already
partially out of date by now 
I'll have to wait until I can get hold of Pickaxe2 (I was too busy
hacking rpa-base/RPA to apply for a review :), but the TOC[1] makes me
suspect that what I'd have liked and what happened are quite dissimilar 
[1]
Package management with RubyGems
* Installing RubyGems
* Installing Application Gems
* Installing and Using Gem Libraries
* Creating your Own Gems
On Fri, Sep 03, 2004 at 07:32:05AM +0900, Carl Youngblood wrote:
I was just drooling in anticipation for pickaxe 2 and looking through
the table of contents on the pragprog web site. I know this is
probably asking too much considering its recent release, but rpa-base
wasn't too far behind ruby-gems in being released, and I believe it is
definitely a worthy contender in the ruby package management arena. I
was disappointed to see that it wasn't included in the book, although
a whole chapter was devoted to ruby-gems.
--
Running Debian GNU/Linux Sid (unstable)
batsman dot geo at yahoo dot com
I think I understand the basic difference, but I was mainly commenting
on its conspicuous absence in pickaxe 2.
On Fri, 3 Sep 2004 08:02:41 +0900, Chad Fowler <chadfowler@gmail.com> wrote:
On Fri, 3 Sep 2004 07:32:05 +0900, Carl Youngblood > > > <carl.youngblood@gmail.com> wrote:
> I was just drooling in anticipation for pickaxe 2 and looking through
> the table of contents on the pragprog web site. I know this is
> probably asking too much considering its recent release, but rpa-base
> wasn't too far behind ruby-gems in being released, and I believe it is
> definitely a worthy contender in the ruby package management arena. I
> was disappointed to see that it wasn't included in the book, although
> a whole chapter was devoted to ruby-gems.I think the fundamental difference is that RubyGems requires
developers to package their own software whereas RPA is meant to be a
repository with a central team doing the packaging. Most of the
RubyGems content in the pickaxe is about how to create gems.
Ultimately, if gems become ubiquitous, it makes the RPA team's
(Mauricio, that is) job easier, because some thought will have to be
put into how to make software distributable in this kind of way[1]. I
see it as a win for everyone.Chad (who wrote the rubygems chapter for pickaxe2)
[1] For an example, check
You are in a maze of twisty little passages, all alike. // halo • statue
I'd have liked a chapter on good practices, which would benefit all
repackagers -- making not only RPA's, but also FreeBSD's, Debian's,
etc job easier. I actually consider this *much* more important than a
detailed explanation of how to use RubyGems or rpa-base: good practices
are more stable than packaging technology, esp. in the initial stages.
Indeed. Next to coding style, this an import part of a software
project/program. Until now I haven't looked into gems very much, I was
satisfied with what was available in Debian, but I'm bound to need some
more libraries so also will package some stuff, since I don't intend
to use gems in such a way that I bypass the build system.
So, it is nice to have a packaging standard which not enforces but
stimulates those best practices. For example requiring/stimulating/forcing
the coder to do 'require "../../../../../../some/libdir/lib.rb"' because of
a given dir structure, will make it very hard to (re)package the result.
Looking at the TOC of Pickaxe 2ed, it seems that chapter is very much
focused on RubyGems; I'd have preferred a general overview, followed by
an explanation of Aoki's setup.rb and then some short notes about how to
use RubyGems and most importantly where to find up-to-date documentation.
IMHO it makes little sense to give too many details since the specifics
are still subject to frequent changes. For instance, if that chapter
mentioned something about require_gem vs. stubs, it'd be already
partially out of date by now
I agree completely, but since it's at the printers, there's nothing to
do about it. Maybe this general overview can be written anyway and put on
www.ruby-doc.org, since it is becoming more and more a central point for
this sort of things.
Paul
On Fri, Sep 03, 2004 at 06:00:46PM +0900, Mauricio Fernández wrote:
--
Student @ Eindhoven | JID: paul@luon.net
University of Technology, The Netherlands | email: paul@luon.net
Using the Power of Debian GNU/Linux <<< | GnuPG: finger paul@luon.net
The chapter is purely about RubyGems: from a user perspective and from a developer's. It's a shame that you couldn't find some time to become involved in the review process: your suggestions then could have helped shape the chapter. There's not much I can do about them now, as the book is at the printers.
Cheers
Dave
On Sep 3, 2004, at 4:00, Mauricio Fernández wrote:
Looking at the TOC of Pickaxe 2ed, it seems that chapter is very much
focused on RubyGems; I'd have preferred a general overview, followed by
an explanation of Aoki's setup.rb and then some short notes about how to
use RubyGems and most importantly where to find up-to-date documentation.
Mauricio Fernández wrote:
I'd have liked a chapter on good practices, which would benefit all
repackagers -- making not only RPA's, but also FreeBSD's, Debian's,
etc job easier. I actually consider this *much* more important than a
detailed explanation of how to use RubyGems or rpa-base: good practices
are more stable than packaging technology, esp. in the initial stages.
It's been a coupla years, but there's a wiki page devoted to this (naming your project, structuring it, using install.rb/setup.rb, etc.): http://rubygarden.org/ruby?QuickGuideToPackaging
I'll also be covering this in chapter 8 of the (Poignant) Guide. I won't be releasing that chapter until next spring, so if you have input, I'd slurp it up.
_why
I think I understand the basic difference, but I was mainly commenting
on its conspicuous absence in pickaxe 2.
I may not have been clear. I should have said "the fundamental
difference driving this decision". My point is that there isn't much
to explain w.r.t RPA, since it isn't the developer's job to create
packages with it. The goal of the RubyGems chapter in the pickaxe
(speaking for myself, at least) is to show Ruby developers a
repeatable way to create packages that can be easily distributed and
installed.
To repeat my sentiment from the earlier post, I think this is a win
for any package manager. If there are more gems, it's easier to make
RPA ports. If there are more RPA ports, it's easier for the
developers to take those ports and the changes required to make them
work and creat gems.
Chad
On Fri, 3 Sep 2004 08:06:28 +0900, Carl Youngblood <carl.youngblood@gmail.com> wrote:
On Fri, 3 Sep 2004 08:02:41 +0900, Chad Fowler <chadfowler@gmail.com> wrote:
> On Fri, 3 Sep 2004 07:32:05 +0900, Carl Youngblood > > > > > > <carl.youngblood@gmail.com> wrote:
> > I was just drooling in anticipation for pickaxe 2 and looking through
> > the table of contents on the pragprog web site. I know this is
> > probably asking too much considering its recent release, but rpa-base
> > wasn't too far behind ruby-gems in being released, and I believe it is
> > definitely a worthy contender in the ruby package management arena. I
> > was disappointed to see that it wasn't included in the book, although
> > a whole chapter was devoted to ruby-gems.
>
> I think the fundamental difference is that RubyGems requires
> developers to package their own software whereas RPA is meant to be a
> repository with a central team doing the packaging. Most of the
> RubyGems content in the pickaxe is about how to create gems.
> Ultimately, if gems become ubiquitous, it makes the RPA team's
> (Mauricio, that is) job easier, because some thought will have to be
> put into how to make software distributable in this kind of way[1]. I
> see it as a win for everyone.
>
> Chad (who wrote the rubygems chapter for pickaxe2)
>
> [1] For an example, check
> You are in a maze of twisty little passages, all alike. // halo • statue
>
>
I'd seen it before: I'd have liked an expanded version of that (with
a few words on version numbering, documentation with rdoc, how to write
well-behaved tests, etc) to be given at least as much importance as
RubyGems' specifics.
I believe Aoki's setup.rb could have been a good standard for "vendor
neutral" (packager-friendly) pristine sources.
On Sat, Sep 04, 2004 at 12:28:06AM +0900, why the lucky stiff wrote:
It's been a coupla years, but there's a wiki page devoted to this
(naming your project, structuring it, using install.rb/setup.rb, etc.):
Captcha
--
Running Debian GNU/Linux Sid (unstable)
batsman dot geo at yahoo dot com
I see what you're saying. Thanks for the explanation. Don't know if
you've already explained it in the book, but this same explanation you
gave me would probably be worth putting in.
On Fri, 3 Sep 2004 08:09:31 +0900, Chad Fowler <chadfowler@gmail.com> wrote:
On Fri, 3 Sep 2004 08:06:28 +0900, Carl Youngblood > <carl.youngblood@gmail.com> wrote:
> I think I understand the basic difference, but I was mainly commenting
> on its conspicuous absence in pickaxe 2.
>
>I may not have been clear. I should have said "the fundamental
difference driving this decision". My point is that there isn't much
to explain w.r.t RPA, since it isn't the developer's job to create
packages with it. The goal of the RubyGems chapter in the pickaxe
(speaking for myself, at least) is to show Ruby developers a
repeatable way to create packages that can be easily distributed and
installed.To repeat my sentiment from the earlier post, I think this is a win
for any package manager. If there are more gems, it's easier to make
RPA ports. If there are more RPA ports, it's easier for the
developers to take those ports and the changes required to make them
work and creat gems.Chad
>
> On Fri, 3 Sep 2004 08:02:41 +0900, Chad Fowler <chadfowler@gmail.com> wrote:
> > On Fri, 3 Sep 2004 07:32:05 +0900, Carl Youngblood > > > > > > > > > <carl.youngblood@gmail.com> wrote:
> > > I was just drooling in anticipation for pickaxe 2 and looking through
> > > the table of contents on the pragprog web site. I know this is
> > > probably asking too much considering its recent release, but rpa-base
> > > wasn't too far behind ruby-gems in being released, and I believe it is
> > > definitely a worthy contender in the ruby package management arena. I
> > > was disappointed to see that it wasn't included in the book, although
> > > a whole chapter was devoted to ruby-gems.
> >
> > I think the fundamental difference is that RubyGems requires
> > developers to package their own software whereas RPA is meant to be a
> > repository with a central team doing the packaging. Most of the
> > RubyGems content in the pickaxe is about how to create gems.
> > Ultimately, if gems become ubiquitous, it makes the RPA team's
> > (Mauricio, that is) job easier, because some thought will have to be
> > put into how to make software distributable in this kind of way[1]. I
> > see it as a win for everyone.
> >
> > Chad (who wrote the rubygems chapter for pickaxe2)
> >
> > [1] For an example, check
> > You are in a maze of twisty little passages, all alike. // halo • statue
> >
> >
>
>
No, but with all due respect to Chad, this isn't actually what happened. There was no decision to omit rpa-base on any grounds: it just hadn't made it onto the radar at the point the book contents were set.
Cheers
Dave
On Sep 2, 2004, at 18:09, Chad Fowler wrote:
I may not have been clear. I should have said "the fundamental
difference driving this decision".
this page should really be on ruby-lang.org no?
-a
On Sat, 4 Sep 2004, Mauricio [iso-8859-1] Fernández wrote:
On Sat, Sep 04, 2004 at 12:28:06AM +0900, why the lucky stiff wrote:
It's been a coupla years, but there's a wiki page devoted to this
(naming your project, structuring it, using install.rb/setup.rb, etc.):
http://rubygarden.org/ruby?QuickGuideToPackagingI'd seen it before: I'd have liked an expanded version of that (with
a few words on version numbering, documentation with rdoc, how to write
well-behaved tests, etc) to be given at least as much importance as
RubyGems' specifics.I believe Aoki's setup.rb could have been a good standard for "vendor
neutral" (packager-friendly) pristine sources.
EMAIL :: Ara [dot] T [dot] Howard [at] noaa [dot] gov
PHONE :: 303.497.6469
A flower falls, even though we love it;
and a weed grows, even though we do not love it. --Dogen
===============================================================================
Chad Fowler <chadfowler@gmail.com> writes:
I may not have been clear. I should have said "the fundamental
difference driving this decision". My point is that there isn't
much to explain w.r.t RPA, since it isn't the developer's job to
create packages with it. The goal of the RubyGems chapter in the
pickaxe speaking for myself, at least) is to show Ruby developers a
repeatable way to create packages that can be easily distributed and
installed.
If I read correctly, Carl's query is about rpa-base, not RPA.
While it isn't the developer's job to create packages with (or more
correctly for) RPA, it's perfectly fine, and in fact a Good Thing, for
the developer to create packages that are easily distributed and
installed with rpa-base.
Massimiliano
p.s.: Mauricio, still unsure about rpa-names? 
Too late - it's at the printers as I type...
Cheers
Dave
On Sep 2, 2004, at 18:26, Carl Youngblood wrote:
I see what you're saying. Thanks for the explanation. Don't know if
you've already explained it in the book, but this same explanation you
gave me would probably be worth putting in.
> I may not have been clear. I should have said "the fundamental
> difference driving this decision".No, but with all due respect to Chad, this isn't actually what
happened. There was no decision to omit rpa-base on any grounds: it
just hadn't made it onto the radar at the point the book contents were
set.
Sorry about that. I should have made it clear that this was a guess.
Chad
On Fri, 3 Sep 2004 08:28:16 +0900, Dave Thomas <dave@pragprog.com> wrote:
On Sep 2, 2004, at 18:09, Chad Fowler wrote: