On 1/10/07, James Edward G. II [email protected] wrote:
like to
gem installany of them?"
</naïve>
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
On Jan 10, 2007, at 13:31, Austin Z. wrote:
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.
Exactly.
–
Eric H. - [email protected] - http://blog.segment7.net
I LIT YOUR GEM ON FIRE!
On 1/10/07, Evan W. [email protected] wrote:
Eric H. 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.
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, Austin Z. [email protected] wrote:
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
Eric H. [email protected] 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 N. [email protected] writes:
# replacement tasks, if anyelse
hoe = Hoe.new(…) do |p|
p.extra_deps = [] # or only your deps.
end
endI 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.
Austin Z. wrote:
On 1/10/07, Evan W. [email protected] wrote:
Eric H. 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.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.
“Austin Z.” [email protected] writes:
Again, this is a Gem problem, not a tattle, hoe, or rubyforge problem.
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.
No dependency is still the best solution.
On Jan 10, 2007, at 4:00 PM, Christian N. wrote:
No dependency is still the best solution.
I agree, even after reading everything that has been said.
James Edward G. II
On Jan 10, 2007, at 4:28 PM, Austin Z. wrote:
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
On 1/10/07, Nathaniel T. [email protected] wrote:
FYI, I originally stripped the hoe dependency from cooloptions, and
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” ™. 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
On 1/10/07, Christian N. [email protected] wrote:
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,
–
Nathaniel T.
<:((><
On 1/10/07, Tim P. [email protected] wrote:
FYI, I originally stripped the hoe dependency from cooloptions, and
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
Evan W. wrote:
IMHO it’s about YAGNI.
–
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 1/11/07, Nathaniel T. [email protected] wrote:
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
On Thu, 2007-01-11 at 17:07 +0900, Pit C. wrote:
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?
Yeah… I don’t quite understand this either. I use Gruff to draw
pretty charts for my Rails app. Gruff depends on hoe, so if I uninstall
hoe, my charts stop working. But Gruff isn’t using hoe while it’s
drawing bar graphs.
Yours,
Tom
Austin Z. schrieb:
On 1/10/07, Tim P. [email protected] wrote:
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?
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
“Nathaniel T.” [email protected] writes:
On 1/10/07, Christian N. [email protected] wrote:
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.
Why would I want to run the Rakefile if I don’t have rake?
The Rakefile merely provides convenience for developers. The software
itself doesn’t need it, and therefore it’s not a real dependency.
On 1/10/07, Austin Z. [email protected] wrote:
do so.
Austin Z. * [email protected] * http://www.halostatue.ca/
* [email protected] * You are in a maze of twisty little passages, all alike. // halo • statue
* [email protected]
The problem is that Gem dependencies currently are run-time
dependencies,
and hoe is using them differently. It seems to me that hoe should
respect
the current definition and uses of dependencies in Gem, rather than act
like
a requested change has already been made. Like it or not, hoe has chosen
to
make itself a run-time dependency, because that’s the only kind there is
right now.
If and when Gems do differentiate between different sorts of
dependencies,
then and only then would it be appropriate for hoe to add itself as a
(non-runtime) dependency.
And going back to an earlier question about whether hoe should be merged
into Gem itself, I would hope that this would not make it any more
difficult
to create and install gems that are intended for an internal corporate
gem
server rather than rubyforge.
Thanks,
On 1/11/07, Pit C. [email protected] wrote:
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?
Well, on Debian at least, gcc, autoconf and the like would be build
dependencies. But point taken.
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?
I guess for me this comes down to the lack of a “compile-time” in Ruby
Lets say, for instance, that I’m a sysadmin and I want to
automatically run the unit tests for all installed gems across a bunch
of machines. I’d much rather not have to manually go through each gem,
figure out what it needs so that I can run its tests, store that
somehow (since it’s not in the spec), install the dependencies since
they aren’t already, and all that to just automatically run tests for
the gems.
I suppose if you think of gems as a static, compiled representation of
Ruby code, hoe becomes a big deal. However, I tend to think of a gem
as more of an object that I can interact with on multiple levels
rather than a ‘compiled’ library that I’m not supposed to touch after
install. It’s probably just my Ruby-addled brain - “But it’s all
runtime, I tell you!”
Now, those who think rubygems should’ve been changed to add
development dependencies first (rather than hoe using the existing
uncategorized dependencies for the time being) have a point, and
should probably not use hoe until that happens. But c’mon people -
it’s a little convenience library, not something anyone is forced in
any way to use. If you feel that strongly about it, just boycott gems
that depend on it.
I just figured it out - you’re all really shills for Zed, aren’t you?
He’s worried about mongrel’s spot in the gem download stats, and he’s
mobilized you all to ensure that hoe doesn’t bump it off! “King of the
Internet” indeed! 
Ruby on,
–
Nathaniel T.
<:((><
This forum is not affiliated to the Ruby language, Ruby on Rails framework, nor any Ruby applications discussed here.
Sponsor our Newsletter | Privacy Policy | Terms of Service | Remote Ruby Jobs