when you install a program under ./bin/ using rubygems it wrappes the code in
a stub - something like
require_gem 'yourapp'
load 'yourapp'
this is all well and good - except that it seems redundant in nearly all
cases. for example my ruby queue package has a program in bin that looks
something like
require_gem 'rq'
RQ::Main::new ARGV, ENV
if i package this with ruby gems this program with get wrapped to look
something like
require_gem 'rq', version
load 'rq'
why? i mean - you must code you programs to require any libraries anyhow -
why would gems wrap these programs by doing the same again? it seems like
programs in ./bin/ should be installed as is. have i missed something
critical here?
regards.
-a
···
--
email :: ara [dot] t [dot] howard [at] noaa [dot] gov
phone :: 303.497.6469
anything that contradicts experience and logic should be abandoned.
-- h.h. the 14th dalai lama
===============================================================================
when you install a program under ./bin/ using rubygems it wrappes the code in
a stub
[...]
why? i mean - you must code you programs to require any libraries anyhow -
why would gems wrap these programs by doing the same again?
So you can load version 1.0.0 vs version 2.0.3 (for example).
wrapped_gem _1.0.0_ rest of args
is how this is done, I think...
it seems like
programs in ./bin/ should be installed as is. have i missed something
critical here?
$ gem help install
Usage: gem install GEMNAME [options]
Options:
-v, --version VERSION Specify version of gem to install
-l, --local Restrict operations to the LOCAL domain (default)
-r, --remote Restrict operations to the REMOTE domain
-b, --both Allow LOCAL and REMOTE operations
-i, --install-dir DIR
-d, --[no-]rdoc Generate RDoc documentation for the gem on install
-f, --[no-]force Force gem to install, bypassing dependency checks
-t, --[no-]test Run unit tests prior to installation
-w, --[no-]wrappers Use bin wrappers for executables
Not available on dosish platforms
^^^^^^^^^^^^^^^^^^^
Courtesy of the first Seattle.rb RubyGems hackfest.
···
On Oct 26, 2005, at 6:33 PM, Ara.T.Howard wrote:
--
Eric Hodel - drbrain@segment7.net - http://segment7.net
FEC2 57F1 D465 EB15 5D6E 7C11 332A 551C 796C 9F04
hmm - i did read the source and see this - i just seems overkill since the app
itself would do this if it cared... most of my production apps are simple two
line scripts that just load a lib. but i guess this could come in handy. it
doesn't seem to work however:
jib:~ > cat `which foo`
#!/dmsp/reference/bin/ruby
···
On Thu, 27 Oct 2005, Eric Hodel wrote:
why? i mean - you must code you programs to require any libraries anyhow -
why would gems wrap these programs by doing the same again?
So you can load version 1.0.0 vs version 2.0.3 (for example).
wrapped_gem _1.0.0_ rest of args
is how this is done, I think...
#
# This file was generated by RubyGems.
#
# The application 'alib' is installed as part of a gem, and
# this file is here to facilitate running it.
#
require 'rubygems'
version = "> 0"
if ARGV.size > 0 && ARGV[0][0]==95 && ARGV[0][-1]==95
if Gem::Version.correct?(ARGV[0][1..-2])
version = ARGV[0][1..-2]
ARGV.shift
end
end
p version
require_gem 'alib', version
p ALib::VERSION
load 'foo'
jib:~ > foo "_> 1.0_"
"> 0"
"0.3.0"
42
in otherwords the version argument doesn't seem to be a gem version - but only
a tripple.
the correct? method gets called later anyhow - the wrapper should pass any
predicate through (~>, >=, etc) and blow up later in require_gem rather that
disallow valid gem versions up front like that.
in this way you can require a program with a know interface but un-known
implementation.
it seems like programs in ./bin/ should be installed as is. have i missed
something critical here?
$ gem help install
Usage: gem install GEMNAME [options]
Options:
-v, --version VERSION Specify version of gem to install
-l, --local Restrict operations to the LOCAL domain (default)
-r, --remote Restrict operations to the REMOTE domain
-b, --both Allow LOCAL and REMOTE operations
-i, --install-dir DIR
-d, --[no-]rdoc Generate RDoc documentation for the gem on install
-f, --[no-]force Force gem to install, bypassing dependency checks
-t, --[no-]test Run unit tests prior to installation
-w, --[no-]wrappers Use bin wrappers for executables
Not available on dosish platforms
^^^^^^^^^^^^^^^^^^^
Courtesy of the first Seattle.rb RubyGems hackfest.
but that's client side. that means that if i put a /bin/sh script or, worse,
a.out program into bin and gem it up i'll depend on every client doing this or
else those programs will be hosed. is there a way to specify this behaviour in
the spec?
regards.
-a
--
email :: ara [dot] t [dot] howard [at] noaa [dot] gov
phone :: 303.497.6469
anything that contradicts experience and logic should be abandoned.
-- h.h. the 14th dalai lama
===============================================================================
$ gem help install
Usage: gem install GEMNAME [options]
Options:
[...]
-w, --[no-]wrappers Use bin wrappers for executables
Not available on dosish platforms
^^^^^^^^^^^^^^^^^^^
Courtesy of the first Seattle.rb RubyGems hackfest.
but that's client side. that means that if i put a /bin/sh script or, worse,
a.out program into bin and gem it up i'll depend on every client doing this or
else those programs will be hosed. is there a way to specify this behaviour in
the spec?
No. We didn't even think of that.
···
On Oct 26, 2005, at 7:21 PM, Ara.T.Howard wrote:
On Thu, 27 Oct 2005, Eric Hodel wrote:
--
Eric Hodel - drbrain@segment7.net - http://segment7.net
FEC2 57F1 D465 EB15 5D6E 7C11 332A 551C 796C 9F04