[ANN] Tattle - The Ruby Census

[James Edward Gray II]

So we've argued for 61,296 more bytes than it takes to download all
three of a hoe packages dependencies.

I find it far more depressing that you and Ryan chose to call this an
argument and handle it as such. I guess I really am just a lot more
dumb you are, because I've been having a conversation and trying to
learn things from it. I really wish it was OK for us to do that.

James Edward Gray II

 

[Jeremy McAnally]

I think one of the concerns is deploying these gems on production
boxes; if an exploit of some sort (God forbid) is found, that's
putting my box in danger. I doubt these gems are in danger of
something like that, but I guess somehow they could be (i.e., flaw in
the rubyforge gem, somehow exploting rake to overwrite files...I don't
know).

For me, it's just a question of principle. For example, I just built
a gem for something I've been working on. It requires hoe because I
used hoe to build it, but it's a very simple library, and as such, my
users will never, ever need hoe (and some may not want it on their
system). Why do I, as the one building the gem, not have the option
to exclude it? Why not just generate a Rakefile and I'll include it
if it needs it; otherwise make a gemspec and build the gem and leave
hoe off the deps.

At least, that's how I would do it. I understand if theres some sort
of other, technical reason far beyond my comprehension.

--Jeremy

This argument (mbox format): 178,544 bytes

rake-0.7.1.gem: 76,800 bytes
rubyforge-0.4.0.gem: 28,160 bytes
hoe-1.1.7.gem: 12,288 bytes

total dependencies for hoe-packaged gems: 117,248 bytes
hoe and rubyforge alone: 40,448 bytes

So we've argued for 61,296 more bytes than it takes to download all
three of a hoe packages dependencies.

Or, you could have downloaded hoe and rubyforge 4.4 times in the
amount of mail spent on this argument.

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

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

 

[Evan Weaver]

total dependencies for hoe-packaged gems: 117,248 bytes
hoe and rubyforge alone: 40,448 bytes

It's not about the filesize. It's about not having to audit and install
packages you don't plan to use in your production systems.

Evan Weaver

 

[Joel VanderWerf]

Eric Hodel wrote:
...

So we've argued for 61,296 more bytes than it takes to download all
three of a hoe packages dependencies.

There are bytes and there are bytes. Some are apples and some are oranges.

Expressing the answer to P=NP is one bit.

How many bits have gone into the discussion of P=NP?

....my 1368 bits added to the noise.

 

[Ryan Davis]

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!

I'm pretty much going to ignore the rest of this bikeshed DIALOG, but
I thought I should respond to this.

For the record:

"On Jan 9, 2007, at 11:33 PM, Ben Bleything wrote:"

was the attribution in my email with the "you're a smart guy"
comment. I know, like, and respect Ben and can say "you're a smart
guy" about/to him without sarcasm. I couldn't possibly say that about
Pit Capitain (since I don't know him).

You might want to actually read the email before you go making
assumptions about me, my intentions, or my thought process.

 

[Austin Ziegler]

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.

Mmm. You need something different yet. You need a platform-specific dependency.

Maybe the dependency list on gems should be a "smart" object:

gem.dependencies << "foo-1.0" # required dependency
gem.dependencies.platform << [ POSIX, "termios-1.0" ]

Probably more work than it's worth

-austin

 

[Austin Ziegler]

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

Only by pretending to be an extension that cheats and uses a
makefile/rakefile to build. I would prefer not to have gems execute
arbitrary code on installation.

-austin
--=20
Austin Ziegler * (e-mail address removed) * http://www.halostatue.ca/
* (e-mail address removed) * http://www.halostatue.ca/feed/
* (e-mail address removed)

 

[Austin Ziegler]

I'm having a hard time with terminology.

Eric means run-time dependencies and idempotency dependencies. Hoe is
required so that someone could take an existing installed gem and
package or repackage it just like the original author does. That's
idempotency.

-a

 

[Austin Ziegler]

You do not mean what I mean when you say "build-time". I think it is
good for a gem to include everything necessary to modify and redeploy
it. I do not think that should extend as far as forcing the user to
install external packages that they would only need if they decided to
do so.

Again, this is a Gem problem, not a tattle, hoe, or rubyforge problem.
The correct solution is to increase the amount of metadata that gems
keep and provide hoe with a way of indicating that it is an
idempotency dependency, not a run-time dependency. hoe-generated gems
are absolutely correct, IMO, in indicating that they depend on hoe for
idempotency. Gems is not correct in not providing this.

-austin

 

[Eric Hodel]

Again, this is a Gem problem, not a tattle, hoe, or rubyforge problem.
The correct solution is to increase the amount of metadata that gems
keep and provide hoe with a way of indicating that it is an
idempotency dependency, not a run-time dependency. hoe-generated gems
are absolutely correct, IMO, in indicating that they depend on hoe for
idempotency. Gems is not correct in not providing this.

Exactly.

 

[Alex LeDonne]

Eric means run-time dependencies and idempotency dependencies. Hoe is
required so that someone could take an existing installed gem and
package or repackage it just like the original author does. That's
idempotency.

Austin-

Thank you - that explains a lot. I did not understand (nor could I
find documented) that idempotency was a design goal of hoe.

I think the discussion came about because some administrators would
consider that a mis-feature for production deployment, and hence the
hoe dependency was unexpected. This may also explain why there has not
been a clamor for idempotency meta-data in RubyGems; it's not a
well-explored or popular use case.

Perhaps a future enhancement to hoe would allow for deploy-only
(non-idempotent) gemspec construction.

-Alex

 

[Michael Greenly]

Again, this is a Gem problem, not a tattle, hoe, or rubyforge problem.
The correct solution is to increase the amount of metadata that gems
keep and provide hoe with a way of indicating that it is an
idempotency dependency, not a run-time dependency. hoe-generated gems
are absolutely correct, IMO, in indicating that they depend on hoe for
idempotency. Gems is not correct in not providing this.

-austin

This most definitely seems to be the minority opinion. The majority
sees this as a strange unexpected behavior of hoe.

 

[James Edward Gray II]

No dependency is still the best solution.

I agree, even after reading everything that has been said.

James Edward Gray II

 

[Ryan Davis]

Eric means run-time dependencies and idempotency dependencies. Hoe is
required so that someone could take an existing installed gem and
package or repackage it just like the original author does. That's
idempotency.

Don't worry Eric. It happens to everyone once in a while... *pat's back*

 

[Nathaniel Talbott]

It is easy to write a rakefile that downgrades itself. Possible gem
hackers will have hoe installed anyway, there is no need to declare
this dependency.

Yes, but in order for the Rakefile to do *anything*, rake would have
to be installed, which it wouldn't necessarily be unless Hoe is a
dependency.

FYI, I originally stripped the hoe dependency from cooloptions, and
have since added it back after further consideration. I'd love to have
development dependencies separated out from runtime dependencies, but
until then, the hoe stays in.

A thought: if code that's not used at runtime is such an issue,
shouldn't we be stripping tests, Rakefiles and the like from our
libraries before gem'ing them? I don't see the difference between
those files and the hoe dependency.

Just my $0.02,

 

[Tim Pease]

Yes, but in order for the Rakefile to do *anything*, rake would have
to be installed, which it wouldn't necessarily be unless Hoe is a
dependency.

FYI, I originally stripped the hoe dependency from cooloptions, and
have since added it back after further consideration. I'd love to have
development dependencies separated out from runtime dependencies, but
until then, the hoe stays in.

A thought: if code that's not used at runtime is such an issue,
shouldn't we be stripping tests, Rakefiles and the like from our
libraries before gem'ing them? I don't see the difference between
those files and the hoe dependency.

Just my $0.02,

My gems do not have the Rakefile included, nor do they depend on Hoe /
RubyForge gems even though I use them and think they are great. Tests
I keep because they can be run from the gem, and it's a nice check if
something goes awry.

When we build and deploy our C++ applications here at work, we do not
distribute the Makefiles or any of our supporting scripts. Same
analogy applies to the Rakefiles and supporting gems.

That being said, it really does not matter one way or the other what
you put in your gem. Unless your gem is full of crap, and then people
won't download it. Hoe and RubyForge are "not crap" (TM). It's just
surprising to some people when they are required.

My rule of thumb is to remove as much as possible from the gem and
still have it work.

Blessings,
TwP

 

[Austin Ziegler]

My gems do not have the Rakefile included, nor do they depend on Hoe /
RubyForge gems even though I use them and think they are great. Tests
I keep because they can be run from the gem, and it's a nice check if
something goes awry.

When we build and deploy our C++ applications here at work, we do not
distribute the Makefiles or any of our supporting scripts. Same
analogy applies to the Rakefiles and supporting gems.

If your C++ application is distributed as source for others to build,
you do. Conisder it this way: if having full idempotency makes it that
much easier for repackagers to consider using something that is
(otherwise) only available as a gem, is it a bad thing?

And yes, I know my opinion on downstream repackagers; by and large, it
hasn't changed.

-austin

 

[M. Edward (Ed) Borasky]

It's not about the filesize. It's about not having to audit and install
packages you don't plan to use in your production systems.

Evan Weaver

IMHO it's about YAGNI.

 

[Pit Capitain]

If your C++ application is distributed as source for others to build,
you do. Conisder it this way: if having full idempotency makes it that
much easier for repackagers to consider using something that is
(otherwise) only available as a gem, is it a bad thing?

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?

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?

Regards,
Pit

 

[Martin DeMello]

A thought: if code that's not used at runtime is such an issue,
shouldn't we be stripping tests, Rakefiles and the like from our
libraries before gem'ing them? I don't see the difference between
those files and the hoe dependency.

No, you should ship them, but *document* rather than hard-enforce the
dependency on make. Likewise, packages that ship with both source and
a precompiled binary in the tarball don't insist that you have gcc
installed before you can install them.

martin