# "ungem" script **URL:** \ **Category:** Ruby\ **Created:** [January 29, 2007, 2:51pm UTC](https://www.ruby-forum.com/t/ungem-script/83751 "2007-01-29T14:51:56Z")\ **Posts on this page:** 8\ **Page:** 1
**Author:** ![sean](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/s/f0a364/32.png) [@sean](https://www.ruby-forum.com/u/sean)\ **Post date:** [January 29, 2007, 2:51pm UTC](https://www.ruby-forum.com/t/ungem-script/83751/1 "2007-01-29T14:51:56Z")
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](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. ---
**Author:** ![sean](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/s/f0a364/32.png) [@sean](https://www.ruby-forum.com/u/sean)\ **Post date:** [January 29, 2007, 3:55pm UTC](https://www.ruby-forum.com/t/ungem-script/83751/2 "2007-01-29T15:55:35Z")
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](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](https://rubyforge.org/tracker/index.php)? func=detail&aid=7980&group\_id=126&atid=575 -Rob Rob B. [http://agileconsultingllc.com](http://agileconsultingllc.com) removed\_email\_address@domain.invalid ---
**Author:** ![sean](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/s/f0a364/32.png) [@sean](https://www.ruby-forum.com/u/sean)\ **Post date:** [January 29, 2007, 5:28pm UTC](https://www.ruby-forum.com/t/ungem-script/83751/3 "2007-01-29T17:28:13Z")
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](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? ---
**Author:** ![sean](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/s/f0a364/32.png) [@sean](https://www.ruby-forum.com/u/sean)\ **Post date:** [January 29, 2007, 5:28pm UTC](https://www.ruby-forum.com/t/ungem-script/83751/4 "2007-01-29T17:28:56Z")
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. ---
**Author:** ![sean](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/s/f0a364/32.png) [@sean](https://www.ruby-forum.com/u/sean)\ **Post date:** [January 29, 2007, 7:11pm UTC](https://www.ruby-forum.com/t/ungem-script/83751/5 "2007-01-29T19:11:59Z")
On 1/29/07, Sean S. [removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid) 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 ---
**Author:** ![sean](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/s/f0a364/32.png) [@sean](https://www.ruby-forum.com/u/sean)\ **Post date:** [January 29, 2007, 9:15pm UTC](https://www.ruby-forum.com/t/ungem-script/83751/6 "2007-01-29T21:15:32Z")
On 1/29/07, Austin Z. [removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid) 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 ---
**Author:** ![sean](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/s/f0a364/32.png) [@sean](https://www.ruby-forum.com/u/sean)\ **Post date:** [January 29, 2007, 5:44pm UTC](https://www.ruby-forum.com/t/ungem-script/83751/7 "2007-01-29T17:44:41Z")
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. ---
**Author:** ![sean](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/s/f0a364/32.png) [@sean](https://www.ruby-forum.com/u/sean)\ **Post date:** [January 29, 2007, 11:31pm UTC](https://www.ruby-forum.com/t/ungem-script/83751/8 "2007-01-29T23:31:02Z")
On 1/29/07, Rob S. [removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid) 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