[ANN] Tattle - The Ruby Census

[Tom Copeland]

So: can any gem developer who consciously includes hoe as a dependency,
explain to me what this allows the gem *user* to do what he couldn't do
otherwise?

Yeah... I don't quite understand this either. I use Gruff to draw
pretty charts for my Rails app. Gruff depends on hoe, so if I uninstall
hoe, my charts stop working. But Gruff isn't using hoe while it's
drawing bar graphs.

Yours,

Tom

 

[Devin Mullins]

To sum up --

For:
* Idempotency -- include everything necessary to allow the gem to be
rebuilt and regemified.
* Repackagers -- make it easier for repackagers by including the
necessary package-time dependencies.
* Developers -- make it easier for developers by including the
dependencies required to run, say, rake test.
* RubyGems -- make hoe a run-time dependency until RubyGems supports
develop-time dependencies.
* seattle.rb -- help up their download stats on rubyforge.

Against:
* Users -- don't waste the time and space of people who aren't in the
above list.
* Sysadmins -- don't add another to the list of software they have to audit.
* Developers -- don't insult their intelligence. They're doing something
outside the scope of a typical user, and know how to read a README and
gem install hoe.
* RubyGems -- don't abuse the "run-time dependency" list just to get
around the lack of a develop-time one.

Did I miss anything? Now, all I think is necessary is a web poll
somewhere, and the dead horse will have been thoroughly beaten.

Devin

 

[Nathaniel Talbott]

When you ship your application with Makefiles, you sure don't ship it
with make and gcc and all the other things that are required to
*execute* the Makefile, do you?

Well, on Debian at least, gcc, autoconf and the like would be build
dependencies. But point taken.

The same applies here: I don't mind if gems are shipped with rakefiles,
even rakefiles which depend on hoe. But why do you think you need to
ship everything needed to execute those rakefiles? As I have proved with
the tattle gem, they absolutely aren't needed to use tattle.

So: can any gem developer who consciously includes hoe as a dependency,
explain to me what this allows the gem *user* to do what he couldn't do
otherwise?

I guess for me this comes down to the lack of a "compile-time" in Ruby
- for a typical user, hoe doesn't do anything. However, as soon as you
want to start interacting with gems on an automated, programatic (we
might even say "meta") level, which I would argue is one "use" of
them, then it becomes much more important.

Lets say, for instance, that I'm a sysadmin and I want to
automatically run the unit tests for all installed gems across a bunch
of machines. I'd much rather not have to manually go through each gem,
figure out what it needs so that I can run its tests, store that
somehow (since it's not in the spec), install the dependencies since
they aren't already, and all that to just automatically run tests for
the gems.

I suppose if you think of gems as a static, compiled representation of
Ruby code, hoe becomes a big deal. However, I tend to think of a gem
as more of an object that I can interact with on multiple levels
rather than a 'compiled' library that I'm not supposed to touch after
install. It's probably just my Ruby-addled brain - "But it's *all*
runtime, I tell you!"

Now, those who think rubygems should've been changed to add
development dependencies *first* (rather than hoe using the existing
uncategorized dependencies for the time being) have a point, and
should probably not use hoe until that happens. But c'mon people -
it's a little convenience library, not something anyone is forced in
any way to use. If you feel that strongly about it, just boycott gems
that depend on it.

I just figured it out - you're all really shills for Zed, aren't you?
He's worried about mongrel's spot in the gem download stats, and he's
mobilized you all to ensure that hoe doesn't bump it off! "King of the
Internet" indeed! ;-)

Ruby on,

 

[Daniel Berger]

To sum up --

For:
* Idempotency -- include everything necessary to allow the gem to be
rebuilt and regemified.
* Repackagers -- make it easier for repackagers by including the
necessary package-time dependencies.
* Developers -- make it easier for developers by including the
dependencies required to run, say, rake test.
* RubyGems -- make hoe a run-time dependency until RubyGems supports
develop-time dependencies.
* seattle.rb -- help up their download stats on rubyforge.

Against:
* Users -- don't waste the time and space of people who aren't in the
above list.
* Sysadmins -- don't add another to the list of software they have to audit.
* Developers -- don't insult their intelligence. They're doing something
outside the scope of a typical user, and know how to read a README and
gem install hoe.
* RubyGems -- don't abuse the "run-time dependency" list just to get
around the lack of a develop-time one.

Did I miss anything?

You forgot to discuss Unicode issues. JOKING!!!

Now, all I think is necessary is a web poll
somewhere, and the dead horse will have been thoroughly beaten.

Well, could this be made configurable within Hoe itself?

spec.idempotent = true

Regards,

Dan

 

[Jeremy Henty]

* Users -- don't waste the time and space of people who aren't in
the above list.

+1 . Surely the point of a packaging system is to serve people who
just want to "wash and go". Why compromise that because someone else
has a problem? "Do one thing, do it well."

* Sysadmins -- don't add another to the list of software they have
to audit.

+1 . (I'm a sysadmin.)

* Developers -- don't insult their intelligence. They're doing
something outside the scope of a typical user, and know how to read
a README and gem install hoe.

+1 . To make it even easier, why not have a "foo" gem for users and a
"foo-dev" gem for developers? Maybe a simple packaging convention is
good enough.

* RubyGems -- don't abuse the "run-time dependency" list just to get
around the lack of a develop-time one.

+1 . Fix the real problem, don't break something else trying to paper
it over.

Regards,

Jeremy Henty

 

[Jeremy Henty]

I'd much rather not have to manually go through each gem, figure out
what it needs so that I can run its tests, store that somehow (since
it's not in the spec), install the dependencies since they aren't
already, and all that to just automatically run tests for the gems.

Maybe a simple convention is all that's needed. (Echoing myself in
another thread.) If the full test set for "foo" is too cumbersome,
release it as "foo-test". It should be easy to write a script that
installs "foo-test" for every installed gem "foo".

(Actually I think that the test-driven philosophy should encourage
developers to think of the tests as just part of the product and
package them as such whenever it is reasonably possible. But there
are bound to be occasions when this is not practical.)

Jeremy Henty

 

[Austin Ziegler]

Maybe a simple convention is all that's needed. (Echoing myself in
another thread.) If the full test set for "foo" is too cumbersome,
release it as "foo-test". It should be easy to write a script that
installs "foo-test" for every installed gem "foo".

(Actually I think that the test-driven philosophy should encourage
developers to think of the tests as just part of the product and
package them as such whenever it is reasonably possible. But there
are bound to be occasions when this is not practical.)

Given your last paragraph, why would idempotency dependencies be any
different than dependencies necessary to run the tests? If I were to
switch all of my unit tests to rspec, would it be appropriate to mark
my gem as depending on rspec? After all, only the people who are going
to run the tests will need it, just as only people who are going to
interact with the gem on a meta-level will need hoe.

-austin

 

[Daniel Berger]

Given your last paragraph, why would idempotency dependencies be any
different than dependencies necessary to run the tests? If I were to
switch all of my unit tests to rspec, would it be appropriate to mark
my gem as depending on rspec? After all, only the people who are going
to run the tests will need it, just as only people who are going to
interact with the gem on a meta-level will need hoe.

How about:

spec = Gem::Specification.new do |gem|
gem.add_dependency("something", ">= 1.2.0")
gem.add_optional("rspec", "Test suite only", ">= 0.5.0")
...
end

And, at the command prompt:

C:\gem install something

Install required dependency something? [Yn]
Install optional dependency rspec (Test suite only) [Yn]
....

And the API would simply be:

Gem#add_optional(gem, comment, *requirements)

Regards,

Dan

 

[Sammy Larbi]

Daniel Berger wrote, On 1/11/2007 12:35 PM:

How about:

spec = Gem::Specification.new do |gem|
gem.add_dependency("something", ">= 1.2.0")
gem.add_optional("rspec", "Test suite only", ">= 0.5.0")
...
end

And, at the command prompt:

C:\gem install something

Install required dependency something? [Yn]
Install optional dependency rspec (Test suite only) [Yn]

The problem I see with that is similar to removing programs in Windows.
Often, it says something to the effect of "it appears no programs are
using the xxxxxx.dll file. Do you want to remove that too?" Well, how
would I know? I don't know what it does. I think any optional
dependencies would need a good description of what it is and why you
would want it. Something better than a small phrase, anyway.

-Sam

 

[Daniel Berger]

Daniel Berger wrote, On 1/11/2007 12:35 PM:

How about:

spec = Gem::Specification.new do |gem|
gem.add_dependency("something", ">= 1.2.0")
gem.add_optional("rspec", "Test suite only", ">= 0.5.0")
...
end

And, at the command prompt:

C:\gem install something

Install required dependency something? [Yn]
Install optional dependency rspec (Test suite only) [Yn]

The problem I see with that is similar to removing programs in Windows.
Often, it says something to the effect of "it appears no programs are
using the xxxxxx.dll file. Do you want to remove that too?" Well, how
would I know? I don't know what it does. I think any optional
dependencies would need a good description of what it is and why you
would want it. Something better than a small phrase, anyway.

Ok, so we do the same thing for uninstalls:

C:\gem uninstall rspec

something-0.1.0 has an optional dependency on [rspec (>= 0.5.0)] (Test
suite only)
Continue with Uninstall? [Yn]

We could also include the optional dependency's description at this
point.

Regards,

Dan

 

[Nathaniel Talbott]

How about:

spec = Gem::Specification.new do |gem|
gem.add_dependency("something", ">= 1.2.0")
gem.add_optional("rspec", "Test suite only", ">= 0.5.0")
...
end

And, at the command prompt:

C:\gem install something

Install required dependency something? [Yn]
Install optional dependency rspec (Test suite only) [Yn]
...

And the API would simply be:

Gem#add_optional(gem, comment, *requirements)

The comment/description idea is excellent, and addresses my main
complaint with generic optional dependencies. Ship it!

 

[Devin Mullins]

Ok, so we do the same thing for uninstalls:

I think the uninstall thing was just an analogy. I believe he was
referring to those types of messages being cryptic in general. "Test
suite only? Why yes, I write unit tests! I guess I have to get rspec,
too." Or say you're installing some logger package... "win32console (for
color messages)? What if I want some in color and some not?"

Meh, those are bad examples. For that matter, I'm not positive a good
example exists. Meh, whatever. I *do* remember that a Gentoo USE
variable of (say) +SSL meant many, many, many different things depending
on what you were installing, but that's neither here nor there.

Devin

 

[Gregory Brown]

interact with the gem on a meta-level will need hoe.

How about:

spec = Gem::Specification.new do |gem|
gem.add_dependency("something", ">= 1.2.0")
gem.add_optional("rspec", "Test suite only", ">= 0.5.0")
...
end

And, at the command prompt:

C:\gem install something

Install required dependency something? [Yn]
Install optional dependency rspec (Test suite only) [Yn]
...

And the API would simply be:

Gem#add_optional(gem, comment, *requirements)

Dan, Excellent approach. I'd love to see this.

 

[Jeremy McAnally]

But the question is would the hoe developers use this? They seem
fairly stuck on this whole idempotentence kick.

--Jeremy

interact with the gem on a meta-level will need hoe.

How about:

spec = Gem::Specification.new do |gem|
gem.add_dependency("something", ">= 1.2.0")
gem.add_optional("rspec", "Test suite only", ">= 0.5.0")
...
end

And, at the command prompt:

C:\gem install something

Install required dependency something? [Yn]
Install optional dependency rspec (Test suite only) [Yn]
...

And the API would simply be:

Gem#add_optional(gem, comment, *requirements)

Dan, Excellent approach. I'd love to see this.

--
My free Ruby e-book:
http://www.humblelittlerubybook.com/book/

My blogs:
http://www.mrneighborly.com/
http://www.rubyinpractice.com/

 

[Gregory Brown]

But the question is would the hoe developers use this? They seem
fairly stuck on this whole idempotentence kick.

Does that really matter? On more than one occasion, Eric and Ryan
have made it clear they simply do not care whether the users of their
software are happy with their decisions in this and other projects.

They're lucky to be talented enough where this kind of stubbornness
doesn't seem to effect them much. It's their code, so it's their
decision how they package things.

I'll be honest, I'd like to give hoe a try, but I won't use it if it
continues to inject itself as it is. Not because I think that Ryan
and Eric are evil or even necessarily *wrong* about this, but because
I personally don't want to be dragging around meta dependencies with
my code.

So if I do try it out, it'll likely be via Evan's forked echoe
project. Sucks to have to do that, but eh, that's the nature of the
beast.

 

[Nathaniel Talbott]

But the question is would the hoe developers use this? They seem
fairly stuck on this whole idempotentence kick.

As far as I'm concerned, optional dependencies preserve idempotency,
and based on Eric's earlier statements on this thread, he seems to
agree. If we get optional dependencies in Rubygems and hoe doesn't
become optional, then I'll start clamoring, too

 

[Austin Ziegler]

But the question is would the hoe developers use this? They seem
fairly stuck on this whole idempotentence kick.

I'm pretty sure that one of the messages in the last ~90 or so
indicated that were optional dependencies available, hoe would use it.

It wouldn't help for anyone who already has hoe-generated gems, of course.

You may not realize it, but you want idempotence, too. One of the
things that can be done with an idempotent gem is that you can
validate a gem on a development server, and then you can repackage and
redeploy that gem on a production server without redownloading it from
the original site.

There's still some work to be done on RubyGems to make this truly
possible without hacks (local installs don't really handle
dependencies well, plus a few other things), but without idempotence,
you're not guaranteed to have everything you need to do that.

-austin

 

[Chris Carter]

I'm pretty sure that one of the messages in the last ~90 or so
indicated that were optional dependencies available, hoe would use it.

It wouldn't help for anyone who already has hoe-generated gems, of course.

You may not realize it, but you want idempotence, too. One of the
things that can be done with an idempotent gem is that you can
validate a gem on a development server, and then you can repackage and
redeploy that gem on a production server without redownloading it from
the original site.

There's still some work to be done on RubyGems to make this truly
possible without hacks (local installs don't really handle
dependencies well, plus a few other things), but without idempotence,
you're not guaranteed to have everything you need to do that.

-austin

So if I were to spend this weekend getting optional/developer-time
dependencies into RubyGems, would people want optional dependencies to
always be prompted, only prompted when a flag is given, or never
prompted?

 

[Gregory Seidman]

I'm pretty sure that one of the messages in the last ~90 or so
indicated that were optional dependencies available, hoe would use it.

It wouldn't help for anyone who already has hoe-generated gems, of course.

You may not realize it, but you want idempotence, too. One of the
things that can be done with an idempotent gem is that you can
validate a gem on a development server, and then you can repackage and
redeploy that gem on a production server without redownloading it from
the original site.

There's still some work to be done on RubyGems to make this truly
possible without hacks (local installs don't really handle
dependencies well, plus a few other things), but without idempotence,
you're not guaranteed to have everything you need to do that.

-austin

[...]
So if I were to spend this weekend getting optional/developer-time
dependencies into RubyGems, would people want optional dependencies to
always be prompted, only prompted when a flag is given, or never
prompted?

Default: no prompt, no install
-Y: no prompt, install
--optional-dependencies: prompt

Chris Carter

--Greg

 

[Gregory Brown]

Default: no prompt, no install
-Y: no prompt, install
--optional-dependencies: prompt

+1

but also, maybe --all-dependencies and --require-dependencies-only or
something as well.
(to aid scripting / aliases)