Install to bin dir?

[T. Onoma]

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?

 

[Chad Fowler]

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?

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

 

[Mauricio Fernández]

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

 

[Ara.T.Howard]

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?

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
--
===============================================================================
| 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
===============================================================================

 

[T. Onoma]

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.

 

[T. Onoma]

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

Now you tell me!

 

[Chad Fowler]

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)

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

 

[T. Onoma]

a modified install.rb:

[snip]

Pretty nice example!

T.

P.S. Thank you, everyone, for all your help!

 

[T. Onoma]

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.

 

[Mauricio Fernández]

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

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.

 

[T. Onoma]

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 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

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.

 

[Gavin Sinclair]

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?

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

 

[T. Onoma]

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?

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.

 

[Mauricio Fernández]

rpa-base has no capital letters

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.

 

[vruz]

[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,

 

[Mauricio Fernández]

[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)

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