[lnkForumImage]
TotalShareware - Download Free Software

Confronta i prezzi di migliaia di prodotti.
Asp Forum
 Home | Login | Register | Search 


 

Forums >

comp.lang.ruby

"ungem" script

sean

1/29/2007 1:52:00 PM

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?...). Also, IM(very)HO there's
just something deeply wrong with a package manager inflicting itself at
program runtime and not just installation time.

--
Posted via http://www.ruby-....

7 Answers

Rob Biedenharn

1/29/2007 2:55:00 PM

0


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?...). 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/...
func=detail&aid=7980&group_id=126&atid=575

-Rob

Rob Biedenharn http://agileconsult...
Rob@AgileConsultingLLC.com




Mike Harris

1/29/2007 4:27:00 PM

0

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?...). 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?

Sean Surname

1/29/2007 4:29:00 PM

0

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.

--
Posted via http://www.ruby-....

Sean Surname

1/29/2007 4:45:00 PM

0

Mike Harris 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.

--
Posted via http://www.ruby-....

Austin Ziegler

1/29/2007 6:12:00 PM

0

On 1/29/07, Sean Surname <sorourke+ruby-forum@ucsd.edu> wrote:
> Mike Harris 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
--
Austin Ziegler * halostatue@gmail.com * http://www.halo...
* austin@halostatue.ca * http://www.halo...feed/
* austin@zieglers.ca

Rob Sanheim

1/29/2007 8:14:00 PM

0

On 1/29/07, Austin Ziegler <halostatue@gmail.com> wrote:
> On 1/29/07, Sean Surname <sorourke+ruby-forum@ucsd.edu> wrote:
> > Mike Harris 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.)

Can you talk more about that last part? Or point to more
resources/threads on it?

- Rob

Austin Ziegler

1/29/2007 10:30:00 PM

0

On 1/29/07, Rob Sanheim <rsanheim@gmail.com> 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.halo...
* austin@halostatue.ca * http://www.halo...feed/
* austin@zieglers.ca