I’m trying to get-up-to-date with Ruby community happenings and jump on
the RubyGems band wagon for an upcoming Rockit release.
A q arises: What to include in a gem?
Seems many of the existing gems includes most of the files traditionally
supplied in a tarball. To me that seems kind of strange since the files
will end up in a dir which is “hidden” (well not really but mentally)
from the user and thus not easily available/visible. Also if everything
goes into the gem (README, docs, samples etc) then it is included in
every version and there might be bloat/duplication etc. So my instinct
tells me to only put the necessary files into the gem but then the gem
cannot replace a normal tarball since users will not get the README,
docs, samples, tests etc. So in the future we will still need ordinary
tarballs even if gems take on? Can someone ease my confusion?
I say put everything in. Don’t worry about duplication, because most
people will only keep one version on the machine anyway.
It’s better to include docs etc. than not. Their very presence
encourages the gem interface to find ways of accessing them.
Here’s a tip. Every gem you install, include the flag “–gen-rdoc”.
That generates the RDoc for that gem. Yes, it’s in a “hidden”
directory, but here’s the trick: run “gem_server” and point your
browser to http://localhost:8808, and you can access all your
installed documentation from one convenient place.
See what I mean?
One day I will implement ‘gem --readme’, allowing users to read the
README file for any installed gem. We’ll see if it’s practical, and
whether it is accepted, but obviously commands like that can only
develop if all the files are there.
In short, there should be no need in the future for tarballs.
Cheers,
Gavin
···
On Monday, March 22, 2004, 7:55:00 AM, Robert wrote:
Hi,
I’m trying to get-up-to-date with Ruby community happenings and jump on
the RubyGems band wagon for an upcoming Rockit release.
A q arises: What to include in a gem?
Seems many of the existing gems includes most of the files traditionally
supplied in a tarball. To me that seems kind of strange since the files
will end up in a dir which is “hidden” (well not really but mentally)
from the user and thus not easily available/visible. Also if everything
goes into the gem (README, docs, samples etc) then it is included in
every version and there might be bloat/duplication etc. So my instinct
tells me to only put the necessary files into the gem but then the gem
cannot replace a normal tarball since users will not get the README,
docs, samples, tests etc. So in the future we will still need ordinary
tarballs even if gems take on? Can someone ease my confusion?
can I say that this is, imo, wrong?
–gen-rdoc should be the default, and if doc generation fails a big
banner should appear, like “Blame the author of this pkg, cause he did
not document it”. Same for tests.
We need to enforce best practices, as a community
Here’s a tip. Every gem you install, include the flag “–gen-rdoc”.
That generates the RDoc for that gem. Yes, it’s in a “hidden”
directory, but here’s the trick: run “gem_server” and point your
browser to http://localhost:8808, and you can access all your
installed documentation from one convenient place.
It would be nice if there were a RubyReview team, which tried out newly
arrived packages. They write a short review about what it is, and they
rate the quality of the package [between 1…10].
is it well tested: 7
fullfill its goal: 9
documentation: 3
It will take lots of effort. Its probably better to enforce that
documentation + test must be supplied.
···
On Sun, 21 Mar 2004 23:11:14 +0000, gabriele renzi wrote:
Here’s a tip. Every gem you install, include the flag “–gen-rdoc”.
That generates the RDoc for that gem. Yes, it’s in a “hidden”
directory, but here’s the trick: run “gem_server” and point your
browser to http://localhost:8808, and you can access all your
installed documentation from one convenient place.
can I say that this is, imo, wrong?
–gen-rdoc should be the default, and if doc generation fails a big
banner should appear, like “Blame the author of this pkg, cause he did
not document it”. Same for tests.
We need to enforce best practices, as a community
–
Simon Strandgaard
I wish I could spawn some more instances of me
It would be nice if there were a RubyReview team, which tried out newly
arrived packages. They write a short review about what it is, and they
rate the quality of the package [between 1..10].
is it well tested: 7
fullfill its goal: 9
documentation: 3
Everybody should be able to do this, we don't need a team. And the
rating should always make it possible to add comments, like amazon
reviews.
I do the same thing, except with a simple ruby script instead of rake. I’m
not sure how well a general release system will work though. Is it going to
be capable of building .debs, .rpms for the various rpm-based distros,
something for Gentoo, Windows, etc? That sounds like a lot of extra work.
Almost exactly like where the GNU Autotools are headed. Frankly, I can’t
stomach the thought of having to write something like Rakefile.am and
Rakefile.ac. I’ll stick with a basic setup and let RubyGems do all the
distribution work.
Leon
···
On Tue, Mar 23, 2004 at 05:29:29AM +0900, Simon Strandgaard wrote:
Same thing here… evolving over time, gets refined for every release I do.
One day, one should make a full-blown general release system.
def on_success(&block)
@event['success'] = block
end
I want the above method to be defined dynamically
def define_my_method(symbol)
....
...
....
....
end
any call to define_my_method(:success) should result in
def on_success(&block)
@event['success'] = block
end
and will be used as
myobject.on_success(){
p "Success"
}
I tried using define_method but am having problems in passing a block.
def on_success(&block) @event[‘success’] = block
end
I want the above method to be defined dynamically
def define_my_method(symbol)
…
…
…
…
end
any call to define_my_method(:success) should result in
def on_success(&block) @event[‘success’] = block
end
and will be used as
myobject.on_success(){
p “Success”
}
I tried using define_method but am having problems in passing a block.
I think that’s just a limitation of define_method–you can define a
method with a specified a parameter list, but not with the ability to
receive a block. The first example below is the best I could come up
with using define_method–you’ve probably gotten this far as well. The
second example works as you want (AFAIU), but uses class_eval.
···
===============
class C
def self.define_my_method(symbol)
define_method(“on_#{symbol}”) do |handler| @event ||= {} @event[symbol] = handler # Proc.new fails
end
end
def handle(condition) @event[condition].call
end
end
c = C.new
c.on_success(proc {
puts “handled success”
})
c.on_failure(proc {
puts “handled failure”
})
c.handle(“success”)
c.handle(“failure”)
===============
class C
def self.define_my_method(symbol)
# should check that symbol is legit
class_eval %{
def on_#{symbol}(&handler) @event ||= {} @event[“#{symbol}”] = handler
end
}
end
def on_success(&block) @event[‘success’] = block
end
I want the above method to be defined dynamically
def define_my_method(symbol)
…
…
…
…
end
any call to define_my_method(:success) should result in
def on_success(&block) @event[‘success’] = block
end
and will be used as
myobject.on_success(){
p “Success”
}
I tried using define_method but am having problems in passing a block.
It doesn’t look like you can use #define_method, since blocks can’t do
the nifty &block conversion trick with their arguments. You may have to
break down and use eval:
def define_my_method(symbol)
eval <<-EOC
def on_#{symbol}(&block) @event[‘#{symbol}’] = block
end
EOC
end
