From: “Devin M.” [email protected]
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
On Jan 10, 2007, at 9:51 AM, Eric H. 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?
James Edward G. II
On 1/10/07, Eric H. [email protected] 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.
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 Jan 10, 2007, at 02:02, Evan W. wrote:
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=5922I 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.
–
Eric H. - [email protected] - http://blog.segment7.net
I LIT YOUR GEM ON FIRE!
On Jan 10, 2007, at 07:57, James Edward G. II wrote:
On Jan 10, 2007, at 9:51 AM, Eric H. 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?
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 H. - [email protected] - http://blog.segment7.net
I LIT YOUR GEM ON FIRE!
Eric H. 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 W.
On Jan 10, 2007, at 08:16, Alex LeDonne wrote:
On 1/10/07, Eric H. [email protected] 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.
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.
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 H. - [email protected] - http://blog.segment7.net
I LIT YOUR GEM ON FIRE!
On 2007-01-10, Eric H. [email protected] 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.
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 H.
On 1/10/07, Eric H. [email protected] wrote:
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.
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 Wed, Jan 10, 2007, Devin M. wrote:
Pit C. wrote:
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!
Actually, he was insulting me, apparently for daring to have a different
opinion than he. I’m hurt, truly.
Ben
On Thu, Jan 11, 2007, Eric H. wrote:
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
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 H. - [email protected] - http://blog.segment7.net
I LIT YOUR GEM ON FIRE!
On Jan 10, 2007, at 2:07 PM, Eric H. wrote:
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 G. II
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
On 1/10/07, Eric H. [email protected] wrote:
three of a hoe packages dependencies.
–
My free Ruby e-book:
http://www.humblelittlerubybook.com/book/
My blogs:
Eric H. 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.
Ok it’s not very clever but… I’ve used FreeRIDE to code my program.
No,
better, Eclipse. Should I add it as a dependency to my library ?
In mongrel and rfuzz, some C code is generated by ragel. Should I add it
as
a dependency ?
Okay okay, don’t hit me 
I really think that runtime (ak. from gem) and developping (ak. from
your
favourite SCM) dependencies should not be the same. But having hoe and
rubyforge won’t kill me
Cheers,
zimbatm
Eric H. wrote:
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 W.
On 1/10/07, James Edward G. II [email protected] wrote:
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.
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
On Jan 10, 2007, at 9:15 AM, Devin M. wrote:
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 B. 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 C. (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.
On 1/10/07, Alex LeDonne [email protected] wrote:
On 1/10/07, Eric H. [email protected] 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.
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