Forum: Ruby "ungem" script

Announcement (2017-05-07): www.ruby-forum.com is now read-only since I unfortunately do not have the time to support and maintain the forum any more. Please see rubyonrails.org/community and ruby-lang.org/en/community for other Rails- und Ruby-related community platforms.
43b5a602ff137983d069f23196fa9e8b?d=identicon&s=25 sean (Guest)
on 2007-01-29 14:51
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.
Ef3aa7f7e577ea8cd620462724ddf73b?d=identicon&s=25 Rob Biedenharn (Guest)
on 2007-01-29 15:55
(Received via mailing list)
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

Rob Biedenharn    http://agileconsultingllc.com
Rob@AgileConsultingLLC.com
97cbca14d17274370cce501bbea7980a?d=identicon&s=25 Mike Harris (gfunk911)
on 2007-01-29 17:28
(Received via mailing list)
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?
34a5d7d53f708a235bdb08057551723d?d=identicon&s=25 Sean Surname (sean---)
on 2007-01-29 17:28
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.
34a5d7d53f708a235bdb08057551723d?d=identicon&s=25 Sean Surname (sean---)
on 2007-01-29 17:44
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.
31ab75f7ddda241830659630746cdd3a?d=identicon&s=25 Austin Ziegler (austin)
on 2007-01-29 19:11
(Received via mailing list)
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
Df5e7adb20adae6c120b04e7cafb15a0?d=identicon&s=25 Rob Sanheim (rsanheim)
on 2007-01-29 21:15
(Received via mailing list)
On 1/29/07, Austin Ziegler <halostatue@gmail.com> 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
31ab75f7ddda241830659630746cdd3a?d=identicon&s=25 Austin Ziegler (austin)
on 2007-01-29 23:31
(Received via mailing list)
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
This topic is locked and can not be replied to.