I know there's probably a ready made solution for this. And I know its been
done ten thousand times before. That's exactly why I'll just ask rather then
reinvent the wheel.
I have an install.rb script which works fine for lib files, but does nothing
for bin files. Anyone have a good code snip for determining where to put bin
files during installation?
--
T.
Quite easy with RubyGems:
http://rubygems.rubyforge.org/wiki/wiki.pl?CreateAGemInTenMinutes
(specifically look at bindir and executables in the gem spec).
Alternatively, look in RubyGems' install.rb for the part that creates
binary stubs to see how we determine the bin directory.
Chad
On Sat, 28 Aug 2004 06:33:31 +0900, T. Onoma <transami@runbox.com> wrote:
I know there's probably a ready made solution for this. And I know its been
done ten thousand times before. That's exactly why I'll just ask rather then
reinvent the wheel.I have an install.rb script which works fine for lib files, but does nothing
for bin files. Anyone have a good code snip for determining where to put bin
files during installation?
require 'rbconfig'
require 'ftools'
destdir = Config::CONFIG["destdir"]
# ...
exec_files.each do |f|
File.install f, File.join(destdir, File.basename(f)), 0755
end
If you're following the 'standard' source layout (lib/, bin/, etc),
I suggest you use setup.rb from Aoki Minero: that way all you have to
do is copy setup.rb into your source dir, period (in most cases at least).
On Sat, Aug 28, 2004 at 06:33:31AM +0900, T. Onoma wrote:
I know there's probably a ready made solution for this. And I know its been
done ten thousand times before. That's exactly why I'll just ask rather then
reinvent the wheel.I have an install.rb script which works fine for lib files, but does nothing
for bin files. Anyone have a good code snip for determining where to put bin
files during installation?
--
Running Debian GNU/Linux Sid (unstable)
batsman dot geo at yahoo dot com
a modified install.rb:
#!/usr/bin/env ruby
require 'rbconfig'
require 'find'
require 'ftools'
include Config
LIBDIR = "lib"
LIBDIR_MODE = 0644
BINDIR = "bin"
BINDIR_MODE = 0755
$srcdir = CONFIG["srcdir"]
$version = CONFIG["MAJOR"]+"."+CONFIG["MINOR"]
$libdir = File.join(CONFIG["libdir"], "ruby", $version)
$archdir = File.join($libdir, CONFIG["arch"])
$site_libdir = $:.find {|x| x =~ /site_ruby$/}
$bindir = CONFIG["bindir"]
if !$site_libdir
$site_libdir = File.join($libdir, "site_ruby")
elsif $site_libdir !~ %r/#{Regexp.quote($version)}/
$site_libdir = File.join($site_libdir, $version)
end
def install_rb(srcdir=nil, destdir=nil, mode=nil)
path =
dir =
Find.find(srcdir) do |f|
next unless FileTest.file?(f)
next if (f = f[srcdir.length+1..-1]) == nil
next if (/CVS$/ =~ File.dirname(f))
path.push f
dir |= [File.dirname(f)]
end
for f in dir
next if f == "."
next if f == "CVS"
File::makedirs(File.join(destdir, f))
end
for f in path
next if (/\~$/ =~ f)
next if (/^\./ =~ File.basename(f))
File::install(File.join(srcdir, f), File.join(destdir, f), mode, true)
end
end
def ARGV.switch
return nil if self.empty?
arg = self.shift
return nil if arg == '--'
if arg =~ /^-(.)(.*)/
return arg if $1 == '-'
raise 'unknown switch "-"' if $2.index('-')
self.unshift "-#{$2}" if $2.size > 0
"-#{$1}"
else
self.unshift arg
nil
end
end
def ARGV.req_arg
self.shift || raise('missing argument')
end
# main program
libdir = $site_libdir
bindir = $bindir
begin
while switch = ARGV.switch
case switch
when '-d', '--destdir'
libdir = ARGV.req_arg
when '-l', '--libdir'
libdir = ARGV.req_arg
when '-b', '--bindir'
bindir = ARGV.req_arg
else
raise "unknown switch #{switch.dump}"
end
end
rescue
STDERR.puts $!.to_s
STDERR.puts File.basename($0) +
" -d <destdir>" +
" -l <libdir>" +
" -b <bindir>"
exit 1
end
install_rb(LIBDIR, libdir, LIBDIR_MODE)
install_rb(BINDIR, bindir, BINDIR_MODE)
cheers.
-a
On Sat, 28 Aug 2004, T. Onoma wrote:
I know there's probably a ready made solution for this. And I know its been
done ten thousand times before. That's exactly why I'll just ask rather then
reinvent the wheel.I have an install.rb script which works fine for lib files, but does nothing
for bin files. Anyone have a good code snip for determining where to put bin
files during installation?
EMAIL :: Ara [dot] T [dot] Howard [at] noaa [dot] gov
PHONE :: 303.497.6469
A flower falls, even though we love it;
and a weed grows, even though we do not love it. --Dogen
===============================================================================
Quite easy with RubyGems:
http://rubygems.rubyforge.org/wiki/wiki.pl?CreateAGemInTenMinutes
(specifically look at bindir and executables in the gem spec).
No doubt! And I have a setup for that. While it's tempting to take a Gem only
route, I'm thinking it a good idea to hang on to a manual install too. Is
that a good idea? I would like to here the pros and cons of that!
Alternatively, look in RubyGems' install.rb for the part that creates
binary stubs to see how we determine the bin directory.
Thanks, Chad. I've taken a look at the gems install.rb. I grok most of it but
what's this about?
if is_windows_platform
File.open(target+".cmd", "w") do |file|
file.puts "@ruby #{target} %1 %2 %3 %4 %5 %6 %7 %8 %9"
end
end
T.
On Friday 27 August 2004 05:38 pm, Chad Fowler wrote:
Now you tell me! 
On Friday 27 August 2004 06:09 pm, Mauricio Fernández wrote:
On Sat, Aug 28, 2004 at 06:33:31AM +0900, T. Onoma wrote:
> I know there's probably a ready made solution for this. And I know its
> been done ten thousand times before. That's exactly why I'll just ask
> rather then reinvent the wheel.
>
> I have an install.rb script which works fine for lib files, but does
> nothing for bin files. Anyone have a good code snip for determining where
> to put bin files during installation?require 'rbconfig'
require 'ftools'
destdir = Config::CONFIG["destdir"]
# ...
exec_files.each do |f|
File.install f, File.join(destdir, File.basename(f)), 0755
endIf you're following the 'standard' source layout (lib/, bin/, etc),
I suggest you use setup.rb from Aoki Minero: that way all you have to
do is copy setup.rb into your source dir, period (in most cases at least).
--
T.
Pretty nice example!
T.
P.S. Thank you, everyone, for all your help!
On Friday 27 August 2004 06:45 pm, Ara.T.Howard@noaa.gov wrote:
a modified install.rb:
[snip]
require 'rbconfig'
require 'ftools'
destdir = Config::CONFIG["destdir"]
# ...
exec_files.each do |f|
File.install f, File.join(destdir, File.basename(f)), 0755
end
Hmm...
Config::CONFIG["destdir"]
and not?
Config::CONFIG['bindir']
If you're following the 'standard' source layout (lib/, bin/, etc),
I suggest you use setup.rb from Aoki Minero: that way all you have to
do is copy setup.rb into your source dir, period (in most cases at least).
Is setup.rb considered the "premier" way to do it? Looks like it handles
compiling for .so too. Is that right? I wonder if it would be worth turning
setup.rb into a rake extension? (And how hard it would be?).
T.
On Friday 27 August 2004 06:09 pm, Mauricio Fernández wrote:
> Quite easy with RubyGems:
> http://rubygems.rubyforge.org/wiki/wiki.pl?CreateAGemInTenMinutes
> (specifically look at bindir and executables in the gem spec).No doubt! And I have a setup for that. While it's tempting to take a Gem only
route, I'm thinking it a good idea to hang on to a manual install too. Is
that a good idea? I would like to here the pros and cons of that!
Doing both is definitely a good plan for now. But, of course, make
sure your users know which one you prefer (hint hint) 
> Alternatively, look in RubyGems' install.rb for the part that creates
> binary stubs to see how we determine the bin directory.Thanks, Chad. I've taken a look at the gems install.rb. I grok most of it but
what's this about?if is_windows_platform
File.open(target+".cmd", "w") do |file|
file.puts "@ruby #{target} %1 %2 %3 %4 %5 %6 %7 %8 %9"
end
end
This is a hack to create 'shell scripts' for Windows users. It's what
makes, for example, "rake blah" work from the command line in Windows.
It's obviously a little brittle as is. Any ideas for improvement from
Windows experts would be welcome.
Thanks,
Chad
On Sat, 28 Aug 2004 07:42:30 +0900, T. Onoma <transami@runbox.com> wrote:
On Friday 27 August 2004 05:38 pm, Chad Fowler wrote:
Hmm...
Config::CONFIG["destdir"]
and not?
Config::CONFIG['bindir']
Oops, clearly CONFIG["bindir"] -- in fact that was my rather laconic
initial draft ("require 'rbconfig'; bindir = Config::CONFIG['bindir']"),
but I introduced the braino when writing the code above 
> If you're following the 'standard' source layout (lib/, bin/, etc),
> I suggest you use setup.rb from Aoki Minero: that way all you have to
> do is copy setup.rb into your source dir, period (in most cases at least).Is setup.rb considered the "premier" way to do it? Looks like it handles
compiling for .so too. Is that right? I wonder if it would be worth turning
setup.rb into a rake extension? (And how hard it would be?).
IMHO it's still the most comfortable/best general way to create installers
(not "packages") for Ruby libs/apps; it is also repackager-friendly and
promotes good development practices regarding source code structure.
It handles extensions, data dirs... without any problem. Ruby-land would
be a better place if everybody used setup.rb instead of custom installers.
I would have preferred RubyGems to work as a metadata/dependency layer
on top of setup.rb.
I'm not sure I understand what you mean by 'rake extension': if you
really want to do rake install, just copying setup.rb into your source
dir and something like
task :install do
require 'rbconfig'
ruby = File.join(Config::CONFIG["bindir"],
Config::CONFIG['ruby_install_name']) + Config::CONFIG['EXEEXT']
#FIXME: possible win32 issue with / vs \
system "#{ruby} setup.rb"
end
would do.
On Sat, Aug 28, 2004 at 12:04:44PM +0900, T. Onoma wrote:
--
Running Debian GNU/Linux Sid (unstable)
batsman dot geo at yahoo dot com
Funny, two years ago the big names on the block were raainstall and rpkg.
Remember those? Now we have RubyGems and RPA. Did we just long for capital
letters in our packaging systems' titles, or have we really gained better
systems? All kidding aside, has ruby-land improved?
IMHO it's still the most comfortable/best general way to create installers
(not "packages") for Ruby libs/apps; it is also repackager-friendly and
promotes good development practices regarding source code structure.
It handles extensions, data dirs... without any problem. Ruby-land would
be a better place if everybody used setup.rb instead of custom installers.
Curious. I've looked it over some. It looks pretty complete (much larger then
install.rb, that's for sure). But, if it is as good as you suggest (and, mind
you, I do not doubt you are quite correct), I wonder why it has never been
bundled with Ruby? Then I think, maybe it would be except it doesn't lend
itself to being used as a library (i.e. you have to copy and paste it into
your directory.) That may well be the case. Thankfully, it is now potentially
correctable with Rake.
I'm not sure I understand what you mean by 'rake extension': if you
really want to do rake install, just copying setup.rb into your source
dir and something liketask :install do
require 'rbconfig'
ruby = File.join(Config::CONFIG["bindir"],
Config::CONFIG['ruby_install_name']) +
Config::CONFIG['EXEEXT'] #FIXME: possible win32 issue with / vs \
system "#{ruby} setup.rb"
end
Well, that's a start. But what i sneeded is being able to use setup.rb as an
API, so that we could put in a Rakefile:
Rake::SetupTask.new { |st|
st.verbose = true
# and other options for setup
}
Then one could do:
rake setup config
rake setup setup
rake setup install
See how this turns setup into a reusable component? Now you might think:
"What's the big deal? Just Copy setup.rb." But what if the Gem people said
the same thing and the RDoc people, and that Rubyforge publisher script, and
the ... so forth and so on. My program's directory could soon have more
support scripts in it then actual scripts of its own. That's why it's really
nice to encapsulate these things via Rake.
On Saturday 28 August 2004 05:26 am, Mauricio Fernández wrote:
--
T.
Ruby-land has gained a very powerful standard library, thus boosting
the power of software that can be assumed to run on a person's system.
You may notice neither of the capital-letter package managers run on
Ruby 1.6.
Another factor, I imagine, is the increasing amount of software
entreating installation, and the consequent thirst for easier ways of
doing it.
Gavin
On Saturday, August 28, 2004, 10:03:22 PM, T. wrote:
Funny, two years ago the big names on the block were raainstall and rpkg.
Remember those? Now we have RubyGems and RPA. Did we just long for capital
letters in our packaging systems' titles, or have we really gained better
systems?
That may have come across a bit negative. That wasn't my intent. (Hey, I love
RubyGems!) I was really just noting the parallel progression (raainstall ->
RubyGems, rpkg -> RPA), and sincerely asking what have been the notable
improvements over the previous systems.
Thanks,
T.
On Saturday 28 August 2004 08:03 am, T. Onoma wrote:
Funny, two years ago the big names on the block were raainstall and rpkg.
Remember those? Now we have RubyGems and RPA. Did we just long for capital
letters in our packaging systems' titles, or have we really gained better
systems?
> Funny, two years ago the big names on the block were raainstall and rpkg.
> Remember those? Now we have RubyGems and RPA. Did we just long for capital
> letters in our packaging systems' titles, or have we really gained better
rpa-base has no capital letters
> systems?
That may have come across a bit negative. That wasn't my intent. (Hey, I love
RubyGems!) I was really just noting the parallel progression (raainstall ->
RubyGems, rpkg -> RPA), and sincerely asking what have been the notable
improvements over the previous systems.
There are noticeable differences between the systems you mention.
To begin with, RPA is the Ruby Production Archive, a broad project, and
not only a package manager, which is AFAIK unprecedented in ruby-land
(not that it matters anyway). The port/package manager I developed for
RPA is rpa-base (really need a better name it seems).
Now, raainstall was built as a layer on top of RAA, and leveraged the
setup.rb/install.rb from the upstream sources. It could have worked
if setup.rb was used by everybody AND they had normalized the metadata
(the one in RAA is very heterogeneous).
RubyGems aims to become the Ruby standard for publishing and managing
third party libraries. It basically discards the original installers
(custom install.rb scripts or Aoki's setup.rb) and asks the upstream
developer to use the gem as the primary means of distribution.
rpkg replicated much of Debian's dpkg, and used similar metadata and file
formats; it also added the ability to build packages locally. I believe
it didn't quite succeed due to the more restricted stdlib available at
that time, as Gavin pointed out.
RPA doesn't require the upstream developers to do anything besides just
developing their sw., since the RPA team will package and test for them:
of course, it's easier to package a clean upstream release, which uses
setup.rb, than some code with lots of assumptions about the directory
structure, so the former will be more likely to be packaged.
rpa-base could be considered "rpkg's successor" in the sense that it is
driven by the same principles, and draws from the same sources. However,
I wouldn't say that RubyGems is raainstall's successor because they work
very differently: whereas raainstall used the normal setup.rb/install.rb
included in the sources, and hence installed into $prefix, RubyGems
discards setup.rb/install.rb and aims to replace it. Finally, RubyGems
installs into the "gemdir" and a mechanism is being devised to get rid of
the library stubs in $prefix -- but total transparency is hard to achieve.
On Sun, Aug 29, 2004 at 12:52:22AM +0900, T. Onoma wrote:
On Saturday 28 August 2004 08:03 am, T. Onoma wrote:
--
Running Debian GNU/Linux Sid (unstable)
batsman dot geo at yahoo dot com
[snip]
There are noticeable differences between the systems you mention.
To begin with, RPA is the Ruby Production Archive, a broad project, and
not only a package manager, which is AFAIK unprecedented in ruby-land
(not that it matters anyway). The port/package manager I developed for
RPA is rpa-base (really need a better name it seems).
how about rpainstall or rpaget ?
that would keep the raainstall tradition and would make more clear the
difference between the client application and the wider project.
(I tend to avoid hyphens and underscores as much as I can for
command names, but then that's only me)
cheers,
I was thinking of just doing s/rpa-base/rpapkg/.
The command line tool would probably remain as rpa because short == sexy
It is my understanding that the confusion between RPA and its port/package
manager is inherent, so an eventual renaming would not really change the
situation :-/
What do you think? Should the command line tool be renamed too?
rpaget/rpainstall wouldn't do because rpa can also perform queries, update
the port/package info, and in the future configure installed software...
On Sun, Aug 29, 2004 at 04:15:30AM +0900, vruz wrote:
[snip]
> There are noticeable differences between the systems you mention.
> To begin with, RPA is the Ruby Production Archive, a broad project, and
> not only a package manager, which is AFAIK unprecedented in ruby-land
> (not that it matters anyway). The port/package manager I developed for
> RPA is rpa-base (really need a better name it seems).how about rpainstall or rpaget ?
that would keep the raainstall tradition and would make more clear the
difference between the client application and the wider project.
(I tend to avoid hyphens and underscores as much as I can for
command names, but then that's only me)
--
Running Debian GNU/Linux Sid (unstable)
batsman dot geo at yahoo dot com