I’ve used ad hoc stuff for packaging most of my gems. Long ago there
was
hoe… is that still relevant?
In this age of Gemcutter, what should I be using to generate my
gemspecs/build my gems/etc?
On Nov 28, 7:25 pm, Tony A. [email protected] wrote:
[Note: parts of this message were removed to make it a legal post.]
I’ve used ad hoc stuff for packaging most of my gems. Long ago there was
hoe… is that still relevant?In this age of Gemcutter, what should I be using to generate my
gemspecs/build my gems/etc?
Bones, Jeweler and soon and updated version of Hoe for gemcutter’s
push command instead of RubyForge usage.
(in no particular or preferred order)
On Nov 28, 2009, at 10:42 PM, Roger P. wrote:
In this age of Gemcutter, what should I be using to generate my
gemspecs/build my gems/etc?jeweler is what I’m using these days.
I’ve seen several uses of it now and it always strikes me that it’s just
about the same size as a traditional gem specification. Which problem
were we trying to solve with all of these fancy packagers again? 
I’m mostly kidding here. Everyone should use whatever they like, of
course.
James Edward G. II
In this age of Gemcutter, what should I be using to generate my
gemspecs/build my gems/etc?
jeweler is what I’m using these days.
-r
On Sun, Nov 29, 2009 at 12:14 AM, James Edward G. II
[email protected] wrote:
On Nov 28, 2009, at 10:42 PM, Roger P. wrote:
In this age of Gemcutter, what should I be using to generate my
gemspecs/build my gems/etc?jeweler is what I’m using these days.
I’ve seen several uses of it now and it always strikes me that it’s just about the same size as a traditional gem specification. Which problem were we trying to solve with all of these fancy packagers again?
I’m mostly kidding here. Everyone should use whatever they like, of course.
All kidding aside, the main advantage of using any of these tools is
getting some rake tasks to help with the workflow of maintaining and
publishing gems.
I’ve been using Dr. Nic’s newgem which is based on hoe, and adds
things like maintaining a rubyforge web site. I’m considering
switching to using jeweler though.
–
Rick DeNatale
Blog: http://talklikeaduck.denhaven2.com/
Twitter: http://twitter.com/RickDeNatale
WWR: http://www.workingwithrails.com/person/9021-rick-denatale
LinkedIn: http://www.linkedin.com/in/rickdenatale
On Sat, Nov 28, 2009 at 10:14 PM, James Edward G. II
[email protected] wrote:
On Nov 28, 2009, at 10:42 PM, Roger P. wrote:
In this age of Gemcutter, what should I be using to generate my
gemspecs/build my gems/etc?jeweler is what I’m using these days.
I’ve seen several uses of it now and it always strikes me that it’s just about the same size as a traditional gem specification. Which problem were we trying to solve with all of these fancy packagers again?
Jeweler is pretty awesome because in addition to providing rake tasks
like:
rake version:bump
rake gemcutter:release
It will also automatically create your repository on github if you’re
into that.
I haven’t tried the others though.
On Saturday 28 November 2009 11:14:10 pm James Edward G. II wrote:
On Nov 28, 2009, at 10:42 PM, Roger P. wrote:
In this age of Gemcutter, what should I be using to generate my
gemspecs/build my gems/etc?jeweler is what I’m using these days.
I’ve seen several uses of it now and it always strikes me that it’s just
about the same size as a traditional gem specification. Which problem
were we trying to solve with all of these fancy packagers again?
Mostly kidding, too, but I have to agree – the only gems I’ve actually
built
lately have been small enough that I don’t see a real advantage to doing
it
programmatically. The last time I did, the only real point I saw was
getting a
list of files – only needed when I was letting Github build gems, and
directory globbing was not allowed in those gempsecs.
On Nov 28, 2009, at 14:25 , Tony A. wrote:
I’ve used ad hoc stuff for packaging most of my gems. Long ago there was
hoe… is that still relevant?In this age of Gemcutter, what should I be using to generate my
gemspecs/build my gems/etc?
Hoe is still very relevant and is what pretty much all of seattle.rb
uses. It has a great plugin system that makes it very easy to enable
extra features. Raggi wrote a gemcutter plugin that’ll be folded in and
default on the next release.
jeweler is what I’m using these days.
I’ve seen several uses of it now and it always strikes me that it’s just
about the same size as a traditional gem specification. Which problem
were we trying to solve with all of these fancy packagers again?I’m mostly kidding here. Everyone should use whatever they like, of
course.
Yeah now that we no longer publish through github it’s not as much of a
necessity. It does still give you the
s.add_development_dependency ‘x’
it will break that up into the appropriate dependency based on rubygems
version (i.e. it gives you the backwards compatible checks for free),
but beyond that you could probably just stick it in a gemspec anyway.
-r
James Edward G. II:
On Nov 28, 2009, at 10:42 PM, Roger P. wrote:
jeweler is what I’m using these days.
I’ve seen several uses of it now and it always strikes me that
it’s just about the same size as a traditional gem specification.
Well, I have never created a gem myself prior to two-days-ago (and
I’m the kind of person who likes to read the docs a bit before doing
something for the first time) – but now that I wanted to and got the
feeling that Jeweler might be worth a try, it was nice to find out
a five-line Rakefile task and a ‘rake version:bump:…’ followed by
a ‘rake install’ is all I need to get the gemspec recreated, validated,
the gem rolled and subsequently gem-installed.
All this without even knowing what goes into the .gemspec, what ends up
in the .gem file (well, my curiousity won as usual, but still…), nor how
to turn one into the other – and I have the added bonus that once I want
to actually punish the public by publishing the gem, it’s also a single
Rake call away.
(Note that theversion:bump tasks also quietly create a bump commit with
a standard message, while the release task pushes to GitHub and tags the
commit appropriately; at the same time, the ‘jeweler’ command can setup
a new project from scratch with both a fresh GitHub repo and the release
automagic, which can promote some kind of – volundary, of course – nice
standarisation of these things, not to mention the ease of setup.)
— Shot