Pickaxe 2 and rpa-base

[Carl Youngblood]

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

 

[Chad Fowler]

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
http://halostatue.ca/blog/index.cgi/Tech/Ruby/Ruwiki/Deployment.20040902.md

 

[Carl Youngblood]

I think I understand the basic difference, but I was mainly commenting
on its conspicuous absence in pickaxe 2.

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
http://halostatue.ca/blog/index.cgi/Tech/Ruby/Ruwiki/Deployment.20040902.md

 

[Chad Fowler]

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

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
http://halostatue.ca/blog/index.cgi/Tech/Ruby/Ruwiki/Deployment.20040902.md

 

[Dave Thomas]

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

 

[Carl Youngblood]

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 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 07:32:05 +0900, Carl Youngblood


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
http://halostatue.ca/blog/index.cgi/Tech/Ruby/Ruwiki/Deployment.20040902.md

 

[Dave Thomas]

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.


Cheers

Dave

 

[Dave Thomas]

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.

Too late - it's at the printers as I type...

Cheers

Dave

 

[Chad Fowler]

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

 

[Mauricio Fernández]

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

 

[Paul van Tilburg]

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
[/QUOTE]

 

[Dave Thomas]

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.

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

 

[why the lucky stiff]

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

 

[Mauricio Fernández]

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

 

[Ara.T.Howard]

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.

this page should really be on ruby-lang.org no?

-a
--
===============================================================================
| 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
===============================================================================

 

[Massimiliano Mirra - bard]

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