From: Austin Ziegler Date: 2007-01-30T07:30:04+09:00 Subject: Re: "ungem" script On 1/29/07, Rob Sanheim 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 -- Austin Ziegler * halostatue@gmail.com * http://www.halostatue.ca/ * austin@halostatue.ca * http://www.halostatue.ca/feed/ * austin@zieglers.ca