[ANN] Tattle - The Ruby Census

[benjohn]

Mr Gray:

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.

 

[James Edward Gray II]

Mr Gray:

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.

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

James Edward Gray II

 

[Devin Mullins]

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

 

[James Edward Gray II]

What about a custom post-install step that said, "Blah blah blah, =20
these are our recommended dependencies, and here's why. Would you =20
like to `gem install` any of them?"
</na=EFve>

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

James Edward Gray II=

 

[Eric Hodel]

Not true. I need rake to work with Rails, even though I'm not
doing any
development on the Rails libraries. If it were packaged with Hoe, I'd
need to install hoe, but I'd never actually use the Hoe libraries
again.

Bad example. Its required by rails:

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

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 Hodel]

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 Hodel]

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

It supports post-install messages, but nobody reads those, especially =20=

when they scroll off the screen because one package was installed as =20
a dependency of another.

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

--=20
Eric Hodel - (e-mail address removed) - http://blog.segment7.net

I LIT YOUR GEM ON FIRE!

 

[M. Edward (Ed) Borasky]

Mr Gray:


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?

 

[Eric Hodel]

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.

You fixed this the wrong way. The problem is in RubyGems not
allowing you the ability to distinguish between run-time dependencies
and build-time dependencies.

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.

The problem is beyond Hoe's.

Don't fork hoe to fix a problem that exists in RubyGems.

Fix RubyGems instead.

 

[Bill Kelly]

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!

He knew all the tricks. Dramatic irony, metaphor, bathos, puns, parody,
litotes and... satire. He was vicious!




SCNR,

Bill

 

[James Edward Gray II]

The problem is in RubyGems not allowing you the ability to
distinguish between run-time dependencies and build-time dependencies.

This is an interesting idea. Can you explain how this would help?
What would RubyGems do with the two different kinds of dependencies?
How would it end up that we wouldn't just have the combined list
installed on all systems?

James Edward Gray II

 

[Alex LeDonne]

You fixed this the wrong way. The problem is in RubyGems not
allowing you the ability to distinguish between run-time dependencies
and build-time dependencies.

I'm having a hard time with terminology.

If you're deploying a pure ruby gem, then a build-time requirement
which is not a run-time requirement is not a dependency, right?

That is, if build-time does not include any time after the gem is
downloaded to my client box, then stuff you (the maintainer of the
gem) need at build time should not be a dependency in the gem sense.

So "build-time dependencies" should exist in the gem sense only when a
gem requires compilation, I think. If I am mistaken, then the phrase
"build-time dependencies" has some meaning to you which is opaque to
me.

For clarity, I will observe that the gem process has more than build-
and run- time...

Developer-build-time
Download-time
Deploy-time
Local-build time
Run-time

-A

 

[Eric Hodel]

This is an interesting idea. Can you explain how this would help?
What would RubyGems do with the two different kinds of
dependencies? How would it end up that we wouldn't just have the
combined list installed on all systems?

For example, FreeBSD's ports has these two types of dependencies, but
uses them slightly differently than RubyGems would need.

FreeBSD gives you the option of installing a pre-built package or
building from source. An image manipulation tool might require
libpng to run, but to be built from source it would also need libtool
and autoconf.

If you install the package only libpng is installed on your system.

If you install from source then libpng, libtool and autoconf are
installed. You can remove autoconf and libtool at your leisure and
nobody cares.

For RubyGems you might have run-time dependencies (rails needs rake,
activerecord, actionpack, ...) and build-time (or developer)
dependencies (FasterCSV needs rake if you want to run the tests or
add features or fix bugs). By default RubyGems would not install
build-time dependencies.

 

[Eric Hodel]

I'm having a hard time with terminology.

If you're deploying a pure ruby gem, then a build-time requirement
which is not a run-time requirement is not a dependency, right?

Provided RubyGems allows you to make such a distinction, correct. At
present RubyGems dependencies are dependencies, regardless of how
they are used.

That is, if build-time does not include any time after the gem is
downloaded to my client box, then stuff you (the maintainer of the
gem) need at build time should not be a dependency in the gem sense.

So "build-time dependencies" should exist in the gem sense only when a
gem requires compilation, I think. If I am mistaken, then the phrase
"build-time dependencies" has some meaning to you which is opaque to
me.

By "build" I mean work on, not compile. ZenTest is a build-time
dependency for some of my gems because I use its assertion library
when I'm building (adding features to or fixing bugs in) that gem.

 

[Evan Weaver]

You fixed this the wrong way. The problem is in RubyGems not
allowing you the ability to distinguish between run-time dependencies
and build-time dependencies.

I disagree. It's a difference of opinion.

By "build" I mean work on, not compile. ZenTest is a build-time
dependency for some of my gems because I use its assertion library
when I'm building (adding features to or fixing bugs in) that gem.

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.

Evan Weaver

 

[Alex LeDonne]

Provided RubyGems allows you to make such a distinction, correct. At
present RubyGems dependencies are dependencies, regardless of how
they are used.

I'm suggesting that something not required at run-time should not
appear in the gemspec as a dependency; the definition of dependencies
in the gem sense is "the gems that must be installed for this gem to
work." (from http://docs.rubygems.org/read/chapter/20 )

In other words, RubyGems already makes such a distinction.
Dependencies in the gemspec are defined as the run-time dependencies.

By "build" I mean work on, not compile. ZenTest is a build-time
dependency for some of my gems because I use its assertion library
when I'm building (adding features to or fixing bugs in) that gem.

I assert that if I don't need to have ZenTest installed to use your
gem, then ZenTest should not appear in the gemspec as a dependency. If
I want to work on your gems to contribute, I'll use source control to
get your README, which I presume will list development
requirements/dependencies.

-A

 

[Jeremy Henty]

By "build" I mean work on, not compile. ZenTest is a build-time
dependency for some of my gems because I use its assertion library
when I'm building (adding features to or fixing bugs in) that gem.

Just a terminology nitpick, but it sounds like you're talking about
*development* dependencies rather than build dependencies. Rather
like the way many projects require extra dependencies if you build
from a checkout instead of a tarball.

Does that clarify or obscure?

Regards,

Jeremy Henty

 

[Ben Bleything]

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!

Actually, he was insulting me, apparently for daring to have a different
opinion than he. I'm hurt, truly.

Ben

 

[Ben Bleything]

Bad example. Its required by rails:

No, it's exactly the right example. As I said above, rake is required
to *use* rails. For instance, to migrate the database. Not a library
development issue.

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?

The problem is Hoe, though. If it wasn't packaged with Hoe, it wouldn't
require Hoe. Hoe requires Rake. If Hoe didn't force gems it creates to
install Hoe, Rake wouldn't be a dependency.

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.

I agree with you here, for the most part. I think it's rare that people
who are doing development on a gem are actually going to have installed
it via gem, as opposed to checking it out of source control. That makes
your "broken" population very small.

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

I disagree here. In my opinion (and the opinion of others, apparently)
Hoe is doing something that is unnecessary. Your opinion is clearly
different.

Mind you, I'm not really complaining, and I don't think anyone else is
either. Hoe does something that struck people as strange, and asked
about it. That's when people started getting defensive.

Ben

 

[Eric Hodel]

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.