[ANN] Tattle - The Ruby Census

ruby-talk
41

Rake is useful for more than just gem deployment.

Only if you are also developing. If you're just using libraries, it
is useless.

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)
[...]

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.

···

On Jan 9, 2007, at 13:03, Ben Bleything wrote:

On Wed, Jan 10, 2007, Eric Hodel wrote:

--
Eric Hodel - drbrain@segment7.net - http://blog.segment7.net

I LIT YOUR GEM ON FIRE!

42

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

···

On Jan 10, 2007, at 05:07, James Edward Gray 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?

--
Eric Hodel - drbrain@segment7.net - http://blog.segment7.net

I LIT YOUR GEM ON FIRE!

43

Ryan Davis 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.

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.

···

On Jan 10, 2007, at 02:02, Evan Weaver wrote:

--
Eric Hodel - drbrain@segment7.net - http://blog.segment7.net

I LIT YOUR GEM ON FIRE!

44

> 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.

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 Gray II

···

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

On 1/10/07, James Edward Gray II <james@grayproductions.net> wrote:

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

45

Austin Ziegler 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

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:

···

On 1/10/07, James Edward Gray II <james@grayproductions.net> wrote:

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

--
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.

46

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

···

On Jan 10, 2007, at 9:51 AM, Eric Hodel wrote:

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

47

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

···

On 1/10/07, Eric Hodel <drbrain@segment7.net> wrote:

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.

48

Eric Hodel wrote:

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

···

--
Posted via http://www.ruby-forum.com/\.

49

>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:

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

···

On Thu, Jan 11, 2007, Eric Hodel wrote:

50

Eric Hodel <drbrain@segment7.net> writes:

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

In the mean time, you can circumvent this for your own gems like this:

  begin
    require 'hoe'
  rescue LoadError
    # replacement tasks, if any
  else
    hoe = Hoe.new(...) do |p|
      p.extra_deps = # or only your deps.
    end
  end

I request to keep this behavior, intentional or not.

···

--
Christian Neukirchen <chneukirchen@gmail.com> http://chneukirchen.org

51

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 Gray II

···

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.

52

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.

···

On Jan 10, 2007, at 07:57, James Edward Gray II wrote:

On Jan 10, 2007, at 9:51 AM, Eric Hodel wrote:

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?

--
Eric Hodel - drbrain@segment7.net - http://blog.segment7.net

I LIT YOUR GEM ON FIRE!

53

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?

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.

···

On Jan 10, 2007, at 08:16, Alex LeDonne wrote:

On 1/10/07, Eric Hodel <drbrain@segment7.net> wrote:

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

--
Eric Hodel - drbrain@segment7.net - http://blog.segment7.net

I LIT YOUR GEM ON FIRE!

54

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.

···

--
Eric Hodel - drbrain@segment7.net - http://blog.segment7.net

I LIT YOUR GEM ON FIRE!

55

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

···

On 1/10/07, Alex LeDonne <aledonne.listmail@gmail.com> wrote:

On 1/10/07, Eric Hodel <drbrain@segment7.net> wrote:
> 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.

--
Austin Ziegler * halostatue@gmail.com * http://www.halostatue.ca/
               * austin@halostatue.ca * You are in a maze of twisty little passages, all alike. // halo • statue
               * austin@zieglers.ca

56

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

···

On 1/10/07, Evan Weaver <eweaver.spamtrap@gmail.com> wrote:

Eric Hodel wrote:
> 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.

--
Austin Ziegler * halostatue@gmail.com * http://www.halostatue.ca/
               * austin@halostatue.ca * You are in a maze of twisty little passages, all alike. // halo • statue
               * austin@zieglers.ca

57

Christian Neukirchen <chneukirchen@gmail.com> writes:

Eric Hodel <drbrain@segment7.net> writes:

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

In the mean time, you can circumvent this for your own gems like this:

  begin
    require 'hoe'
  rescue LoadError
    # replacement tasks, if any
  else
    hoe = Hoe.new(...) do |p|
      p.extra_deps = # or only your deps.
    end
  end

I request to keep this behavior, intentional or not.

Too bad. For hoe 1.1.7, use:

   begin
     require 'hoe'
   rescue LoadError
     # replacement tasks, if any
   else
     hoe = Hoe.new(...) do |p|
       p.extra_deps = # or only your deps.
     end
     hoe.spec.dependencies.delete_if { |dep| dep.name == "hoe" }
   end

Or really use Echoe.

···

--
Christian Neukirchen <chneukirchen@gmail.com> http://chneukirchen.org

58

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.

59

James Edward Gray 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

60

>
>> 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?

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.

> 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.

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

···

On 1/10/07, Eric Hodel <drbrain@segment7.net> wrote:

On Jan 10, 2007, at 08:16, Alex LeDonne wrote:
> On 1/10/07, Eric Hodel <drbrain@segment7.net> wrote: