Before I go off and write something, has anyone here already written a
script to turn an installed gem into an ordinary installed module?
While more and more modules are available only via rubygems, gems
introduce significant runtime overhead for short-lived commands (see
e.g. http://eigenclass.org/hiki.rb?fastri). Also, IM(very)HO there’s
just something deeply wrong with a package manager inflicting itself at
program runtime and not just installation time.
On Jan 29, 2007, at 8:52 AM, sean wrote:
Before I go off and write something, has anyone here already written a
script to turn an installed gem into an ordinary installed module?
While more and more modules are available only via rubygems, gems
introduce significant runtime overhead for short-lived commands (see
e.g. http://eigenclass.org/hiki.rb?fastri). Also, IM(very)HO
there’s
just something deeply wrong with a package manager inflicting
itself at
program runtime and not just installation time.
You are probably looking for ‘gem unpack’, but it may still have a
bit of a (recently introduced) problem:
https://rubyforge.org/tracker/index.php?
func=detail&aid=7980&group_id=126&atid=575
-Rob
sean wrote:
Before I go off and write something, has anyone here already written a
script to turn an installed gem into an ordinary installed module?
While more and more modules are available only via rubygems, gems
introduce significant runtime overhead for short-lived commands (see
e.g. http://eigenclass.org/hiki.rb?fastri). Also, IM(very)HO there’s
just something deeply wrong with a package manager inflicting itself at
program runtime and not just installation time.
Could you not just install with RubyGems and then invoke the absolute
path of the file manually, instead of requiring or using the RubyGems
bin wrapper?
Thanks. That’s the first part of the solution. The second is a stub
r?ubygems.rb that avoids loading the whole gems mess. The third is a
script that installs via “gem unpack”. I’ll post something when I get
it working.
On 1/29/07, Sean S. [email protected] wrote:
Mike H. wrote:
Could you not just install with RubyGems and then invoke the absolute
path of the file manually, instead of requiring or using the RubyGems
bin wrapper?
It’s a little trickier than that. You need to (1) make modules
available via ordinary ‘require’ instead of ‘require_gem’ (or whatever
we like to use today), (2) prevent “require ‘rubygems’” from insinuating
rubygems into your program, and (3) still allow ‘gem install foo’ to
work for module authors that insiste upon only distributing gems.
require_gem has not been required for a very long time, and is now
deprecated. You just use “require” – after, of course, patching
require with “require ‘rubygems’”.
Frankly, I think anyone who is worried about this is worrying too much
about little things that don’t make big differences.
(Now, there are things that people who write gems should do to make it
so that it doesn’t matter whether you’ve installed a library directly
or as a gem, but that’s a slightly different issue than worrying about
rubygems “intrusion” on runtime, which is nonsensical worrying.)
-austin
On 1/29/07, Austin Z. [email protected] wrote:
rubygems “intrusion” on runtime, which is nonsensical worrying.)
Can you talk more about that last part? Or point to more
resources/threads on it?
- Rob
Mike H. wrote:
Could you not just install with RubyGems and then invoke the absolute
path of the file manually, instead of requiring or using the RubyGems
bin wrapper?
It’s a little trickier than that. You need to (1) make modules
available via ordinary ‘require’ instead of ‘require_gem’ (or whatever
we like to use today), (2) prevent “require ‘rubygems’” from insinuating
rubygems into your program, and (3) still allow ‘gem install foo’ to
work for module authors that insiste upon only distributing gems.
On 1/29/07, Rob S. [email protected] wrote:
(Now, there are things that people who write gems should do to make it
so that it doesn’t matter whether you’ve installed a library directly
or as a gem, but that’s a slightly different issue than worrying about
rubygems “intrusion” on runtime, which is nonsensical worrying.)
Can you talk more about that last part? Or point to more
resources/threads on it?
Some of the process that I use will be changing because I’m probably
going to shift to hoe-generated gems when I get time to work on my
various libraries (they’re not dead! they’re just on major life
support), but I always generate both a .tar.gz with a setup.rb and a
.gem. I have not done so in the past, but the .tar.gz will include the
Rakefile necessary to turn it into a gem, and the .gem will include
setup.rb so that when unpacked it can install nicely.
More than that, I try to make sure that my files don’t explicitly
require Rubygems. If you’re not using gems for a particular library,
it assumes that any dependent libraries are also not installed with
gems. This means that it’s up to the consumer of my application to
say that he’s using Rubygems if, in fact, he is.
Both of these are easier to do than they sound; I make the .tar.gz
with Archive::Tar::Minitar; I don’t use any staging areas during the
build process (my build process assumes an exported checkout, but
excludes CVS and SVN directories anyway).
I used to put a rescue to require RubyGems, but I’m not fond of that
approach anymore. I really want to see RubyGems integrated into core
Ruby and see the path searching that RubyGems does integrated into the
C (or Java, as the case may be). I’d also like to see a path map
cached (which wouldn’t really be that hard, IMO) which may also speed
up RubyGems searches.
-austin