Tattle - The Ruby Census

Ryan D. wrote:

dependencies, then file a bug with rubygems and/or offer them a well
tested patch. Otherwise, drop it as it doesn’t matter one bit.

Maybe instead of complaining for a paragraph about this guy’s behavior,
you could answer his question (in case you’ve forgotten: “Why?”), as
Eric demonstrated.

On Wed, Jan 10, 2007, Ryan D. wrote:

In other words, who cares?!?

At least one other person than me, apparently, since I didn’t ask this
question originally.

It sounds like you’re complaining simply because it offends your
sensibilities. If you have a problem with the way gems does
dependencies, then file a bug with rubygems and/or offer them a well
tested patch. Otherwise, drop it as it doesn’t matter one bit.

I’m not really complaining, just asking. And nobody has answered my
question yet.

It’s not a problem with the way gem handles dependencies. It’s a
problem with hoe injecting itself as a dependency on any gem it creates.
And it’s not really a problem, I just want to know why. You’re acting
like I’m insulting your sister, but I’m really just asking a question.

Ben

On Jan 9, 2007, at 11:33 PM, Ben B. wrote:

It’s not a problem with the way gem handles dependencies. It’s a
problem with hoe injecting itself as a dependency on any gem it
creates.
And it’s not really a problem, I just want to know why.

No, hoe is acting absolutely properly when it injects itself into the
dependency list. Any gem should FULLY list all of its dependencies it
requires to work (defined broadly by rubygems but could be summarized
as “something mentioned by ‘require’”). That would include rake if
you have a Rakefile. Since a Rakefile is just software (a
specification for automated behavior), it too can have dependencies.
Since hoe projects are just rakefiles that use hoe, it has a
dependency on hoe… Without hoe as a dependency, the software
packaged in a hoe-based gem doesn’t work 100%. But… you’re a smart
guy. You knew that.

I found this strange, too. I love hoe, I’m just puzzled as to why
it’s required by the gems it creates.

Not a dealbreaker; just a curiousity. :slight_smile:

–Jeremy

On 1/9/07, Ben B. [email protected] wrote:

sensibilities. If you have a problem with the way gems does

Ben


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

My blogs:

http://www.rubyinpractice.com/

Ryan D. schrieb:

On Jan 9, 2007, at 4:29 AM, Pit C. wrote:

Chad, why does tattle depend on the hoe and rubyforge gems?

Uh… because hoe is the single most awesome thing for ruby project
development in the last 6 years? It is used in 5% of all rubygems.
Get over it.

Plus this answer to Ben:

It sounds like you’re complaining simply because it offends your
sensibilities. If you have a problem with the way gems does
dependencies, then file a bug with rubygems and/or offer them a well
tested patch. Otherwise, drop it as it doesn’t matter one bit.

And:

… Without hoe as a dependency, the software packaged in a hoe-based
gem doesn’t work 100%. But… you’re a smart guy. You knew that.

Ho, ho, ho, calm down, Ryan, I didn’t want to step on your toes or your
“most awesome” project.

I haven’t used hoe yet. From the little I remember of the announcements,
it looked to me like a tool for the gem developer, not for the gem user.
That’s why I asked the question, just out of interest. Why did you think
I was complaining? All I needed was a little “gem uninstall hoe” after
running tattle. This is a small price to pay compared to all the work
the rubygems people are doing. No problem for me.

After all the posts in this thread I still haven’t got a clear answer to
my original question yet. (So much for the signal to noise ratio.)

Eric wrote that hoe is necessary to be able to say “rake test”, and that
“gem install -t” doesn’t work reliably. (BTW: I’m sure you’ve given him
the same advice you gave Ben, namely to file a bug with rubygems, didn’t
you?) I’m not sure where I, as a tattle user, should execute “rake
test”, but I assume it is in the installation directory of the tattle
gem. But in this directory I can also simply enter “testrb test” to run
all the tattle tests. So it seems hoe is of not much use in this case.

You wrote that a gem developed with hoe needs hoe at runtime to work
100%. I did a little test:

gem install tattle (plus hoe, plus rubyforge)
remove the hoe dependency from the tattle gemspec
gem uninstall hoe
gem uninstall rubyforge
run tattle unit tests (with “testrb test”)
run tattle report
run tattle

It seems all is working well, even without hoe. So I’m still curious
what services hoe offers to gems at runtime.

… Without hoe as a dependency, the software packaged in a hoe-based
gem doesn’t work 100%. But… you’re a smart guy. You knew that.

Seems I’m not. I’m still not knowing it.

Regards,
Pit

On Jan 10, 2007, at 12:52 AM, Ryan D. wrote:

Any gem should FULLY list all of its dependencies it requires to
work (defined broadly by rubygems but could be summarized as
“something mentioned by ‘require’”). That would include rake if you
have a Rakefile.

I don’t agree with that.

FasterCSV, for example, has a Rakefile. It makes my life as a
developer easier. I can run tests easier, create releases easier,
etc. It has absolutely nothing to do with running FasterCSV. Rake
is not needed for that, so I think adding it as a dependency is wrong.

If you want to play with FasterCSV’s source, you have two options.
First, you can make sure rake is installed and use all the easy
shortcuts I do. Or, you can do things the slightly longer way. I
even document this. Here’s an excerpt from the FasterCSV documentation:

== Running the Tests

If you would like to run FasterCSV’s test suite on your system before
installing and you have Rake installed, just issue the following
command from the root of the project directory:

$ rake

If you do not have rake, use the following command instead:

$ ruby -I lib:test test/ts_all.rb

-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=

Remember, rake and hoe just automate some commands that can always be
issued manually.

Thinking about it another way, how many precompiled extensions, for
Windows let’s say, include a Makefile? What the heck do you need
that for and how likely is make to be installed?

James Edward G. II

Ryan D. wrote:

No, hoe is acting absolutely properly when it injects itself into the
dependency list. Any gem should FULLY list all of its dependencies it
requires to work (defined broadly by rubygems but could be summarized
as “something mentioned by ‘require’”).

There is a difference of opinion here. Ryan thinks dependencies should
include meta-dependencies. Many people, though, do not. The question has
come up before:

http://rubyforge.org/tracker/index.php?func=detail&aid=5993&group_id=1513&atid=5921
http://rubyforge.org/tracker/index.php?func=detail&aid=7118&group_id=1513&atid=5922

I agree with those who want to avoid installing meta-dependencies on
production servers. So, here is Echoe, a Hoe 1.1.6 fork.

sudo gem install echoe

http://rubyforge.org/frs/?group_id=2835

To use Echoe properly in a Rakefile, load it conditionally, like so:

require ‘rubygems’
require ‘rake’
begin
require ‘echoe’

all your regular Echoe config

rescue LoadError => boom
puts “You are missing a dependency required for meta-operations on
this gem.”
puts “#{boom.to_s.capitalize}.”
desc ‘No effect.’
task :default; end

if you still want tests when Echoe is not present

desc ‘Run the test suite.’
task :test do
system “ruby -Ibin:lib:test some_tests_test.rb” # or whatever
end
end

Personally, I hate Echoe. There is no reason to fork. But I think that
there is a need here, and if the Hoe developers refuse to acknowledge
it, we have no choice.

Evan W.

PS. Ryan, I submitted a patch against Rubyforge 0.4.0 for some stuff.
http://rubyforge.org/tracker/index.php?func=detail&aid=7727&group_id=1024&atid=4027

On Jan 10, 2007, at 7:38 AM, Austin Z. wrote:

included with my gems because of idempotency.
My Rakefile is included. I just don’t make rake a dependency.

What we need to resolve this is recommended dependencies; currently,
RubyGems dependencies are mandatory if present. Hoe should be a
recommended, but not mandatory, dependency.

That makes sense to me.

James Edward G. II

On 1/10/07, James Edward G. II [email protected] wrote:

On Jan 10, 2007, at 12:52 AM, Ryan D. wrote:

Any gem should FULLY list all of its dependencies it requires to
work (defined broadly by rubygems but could be summarized as
“something mentioned by ‘require’”). That would include rake if you
have a Rakefile.
I don’t agree with that.

I didn’t used to. Now, as I get back into Ruby development, I will be
ensuring that the Rakefiles that I use to deploy software are also
included with my gems because of idempotency. Mauricio convinced me of
the value of that.

What we need to resolve this is recommended dependencies; currently,
RubyGems dependencies are mandatory if present. Hoe should be a
recommended, but not mandatory, dependency.

-austin

Austin Z. wrote:

included with my gems because of idempotency. Mauricio convinced me of
the value of that.

What we need to resolve this is recommended dependencies; currently,
RubyGems dependencies are mandatory if present. Hoe should be a
recommended, but not mandatory, dependency.

-austin
I find “recommended dependencies” a pain in the behind, as well as being
an oxymoron. If I install a package, I want to know I’m getting what’s
required and only what’s required. Remember the YAGNI principle –
You Ain’t Gonna Need It!

I work with three package management systems – RubyGems, Gentoo’s
Portage and the R language package management system. R automatically
installs recommended packages, and I end up having to uninstall them in
some cases. And yet R does not tell me when I don’t have an underlying
Linux dependency missing! The way I find that out is by looking at the
log files from a failed install, usually in the configure step. :frowning:


M. Edward (Ed) Borasky, FBG, AB, PTA, PGS, MS, MNLP, NST, ACMC(P)
http://borasky-research.blogspot.com/

If God had meant for carrots to be eaten cooked, He would have given
rabbits fire.

On Jan 10, 2007, at 8:00 AM, M. Edward (Ed) Borasky wrote:

I find “recommended dependencies” a pain in the behind, as well as
being an oxymoron.

I think there is a very real need for them. With HighLine, we would
love the make termios a dependency, because our libraries
functionality is so much better on Unix with it. Unfortunately we
can’t, since it breaks the install process on Windows. A recommended
dependency could help us with this.

James Edward G. II

Pit C. wrote:

Ryan D. schrieb:

… Without hoe as a dependency, the software packaged in a hoe-based
gem doesn’t work 100%. But… you’re a smart guy. You knew that.

Seems I’m not. I’m still not knowing it.

He was applying that cleverist of humor devices known as sarcasm. He was
insulting you. See, by typing “you’re a smart guy” after typing an
explanation he considered to be unnecessary, that’s his was of saying
that you’re not a smart guy. Oh, Ryan, you scoundrel!

Devin

On Jan 10, 2007, at 8:15 AM, [email protected] wrote:

dependency could help us with this.

Isn’t this a case of a platform dependent dependency? The idea of
“platform” could be very general, perhaps, including things like
“I’m on
a Mac, I don’t want to use My SQL, but I do use SQLite”.

We would use that if available too, yes. :wink:

HighLine does work without termios, just not as well. So, in this
case, a recommended or platform dependency would help.

James Edward G. II

Mr Gray:

On Jan 10, 2007, at 8:00 AM, M. Edward (Ed) Borasky wrote:

I find “recommended dependencies” a pain in the behind, as well as
being an oxymoron.

I think there is a very real need for them. With HighLine, we would
love the make termios a dependency, because our libraries
functionality is so much better on Unix with it. Unfortunately we
can’t, since it breaks the install process on Windows. A recommended
dependency could help us with this.

Isn’t this a case of a platform dependent dependency? The idea of
“platform” could be very general, perhaps, including things like “I’m on
a Mac, I don’t want to use My SQL, but I do use SQLite”.

Just a random thought - sorry if it is noise.

On Jan 10, 2007, at 8:20 AM, Devin M. wrote:

</naïve>
That’s an interesting idea. Does gems support post-install scripts?

James Edward G. II

James Edward G. II wrote:

I think there is a very real need for them. With HighLine, we would
love the make termios a dependency, because our libraries functionality
is so much better on Unix with it. Unfortunately we can’t, since it
breaks the install process on Windows. A recommended dependency could
help us with this.

What about a custom post-install step that said, “Blah blah blah, these
are our recommended dependencies, and here’s why. Would you like to gem install any of them?”
</naïve>

Devin

On Jan 9, 2007, at 13:03, Ben B. wrote:

again.
Bad example. Its required by rails:

$ gem dep rails --version=1.1.6
Gem rails-1.1.6
rake (>= 0.7.1)
[…]

I shouldn’t need to install the rubyforge gem to install someone
else’s library, but if they packaged it with hoe, I’m forced to.
This doesn’t make sense.

Same for rake, but nobody complains.

Not true at all:

[…]

I thought this thread was about [hoe packaged project] requires hoe/
rubyforge. In that vein I’ve not seen a thread about [hoe packaged
project] requires rake (or hoe/rubyforge/rake). Why is that?

I think the real complaint is that currently RubyGems has no way to
distinguish between build-time dependencies and run-time
dependencies. Hoe has the option of marking itself as dependent upon
what it needs or creating broken gems (even if only for a small
population). I don’t like the latter so I’m left with the former.

Directing complaints at Hoe is the wrong target. Directing feature
requests and/or patches at RubyGems is the right target.


Eric H. - [email protected] - http://blog.segment7.net

I LIT YOUR GEM ON FIRE!

On Jan 10, 2007, at 06:23, James Edward G. II wrote:

these are our recommended dependencies, and here’s why. Would you
like to gem install any of them?"
</naïve>

That’s an interesting idea. Does gems support post-install scripts?

It supports post-install messages, but nobody reads those, especially
when they scroll off the screen because one package was installed as
a dependency of another.

Instead RubyGems needs built-time and run-time dependencies.


Eric H. - [email protected] - http://blog.segment7.net

I LIT YOUR GEM ON FIRE!

On Jan 10, 2007, at 05:07, James Edward G. II wrote:

Thinking about it another way, how many precompiled extensions, for
Windows let’s say, include a Makefile? What the heck do you need
that for and how likely is make to be installed?

You don’t include makefiles, you include extconf.rb and run it to
generate a Makefile.


Eric H. - [email protected] - http://blog.segment7.net

I LIT YOUR GEM ON FIRE!

[email protected] wrote:

functionality is so much better on Unix with it. Unfortunately we
can’t, since it breaks the install process on Windows. A recommended
dependency could help us with this.

Isn’t this a case of a platform dependent dependency? The idea of
“platform” could be very general, perhaps, including things like “I’m on
a Mac, I don’t want to use My SQL, but I do use SQLite”.

Just a random thought - sorry if it is noise.

Yes, indeed, there are platform dependencies. The point is that someone
has to expend effort at some point. In the specific case of R and Debian
GNU/Linux, for example, a “volunteer” packages a large number of R
packages as Debian packages, so one can use the “apt” mechanisms to
maintain R packages on a Debian system. On Gentoo, there’s another set
of “volunteers” that integrates Ruby packages into Portage, and there’s
even some automation in place – and more on the way. On Windows, yet
another set of “volunteers” has to recompile the R packages with C, C++
or FORTRAN code, as is also the case for Ruby packages with C
extensions. In addition, R packages for Windows typically carry along
binaries of dependencies – for example, the R interfaces to SQLite and
Graphviz install the DLLs required to make them work. I don’t own a Mac,
so I have no idea how all this magic works on a Mac.

So it’s a tradeoff between ease of use for a user base and ease of use
for a distributor. I’d rather have non-requirements be optional by
default and have to explicitly install them than have them install by
default and have to explicitly remove them. So … which is more work
for a distributor, especially if said distributor has to maintain a
source repository and a Windows binary repository? And what happens on
Macs?


M. Edward (Ed) Borasky, FBG, AB, PTA, PGS, MS, MNLP, NST, ACMC(P)
http://borasky-research.blogspot.com/

If God had meant for carrots to be eaten cooked, He would have given
rabbits fire.