Install to bin dir?

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.


0
transami (959)
8/27/2004 9:33:31 PM
comp.lang.ruby 48886 articles. 0 followers. Post Follow

15 Replies
414 Views

Similar Articles

[PageSpeed] 3
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?
> 
> 

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


0
chadfowler1 (309)
8/27/2004 9:38:22 PM
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
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).

-- 
Running Debian GNU/Linux Sid (unstable)
batsman dot geo at yahoo dot com



0
batsman.geo (482)
8/27/2004 10:09:14 PM
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?

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
===============================================================================
0
Ara.T.Howard2 (2805)
8/27/2004 10:35:40 PM
On Friday 27 August 2004 05:38 pm, Chad Fowler 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!

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


0
transami (959)
8/27/2004 10:42:30 PM
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
> 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! ;)

-- 
T.



0
transami (959)
8/27/2004 10:45:42 PM
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:
> > 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


0
chadfowler1 (309)
8/27/2004 10:53:42 PM
On Friday 27 August 2004 06:45 pm, Ara.T.Howard@noaa.gov wrote:
> a modified install.rb:
>
> [snip]

Pretty nice example!

T.

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


0
transami (959)
8/28/2004 2:12:51 AM
On Friday 27 August 2004 06:09 pm, Mauricio Fern�ndez wrote:
> 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.



0
transami (959)
8/28/2004 3:04:44 AM
On Sat, Aug 28, 2004 at 12:04:44PM +0900, T. Onoma 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 :P

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

-- 
Running Debian GNU/Linux Sid (unstable)
batsman dot geo at yahoo dot com



0
batsman.geo (482)
8/28/2004 9:26:33 AM
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?

On Saturday 28 August 2004 05:26 am, Mauricio Fern�ndez wrote:
> 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.

-- 
T.



0
transami (959)
8/28/2004 12:03:22 PM
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? :) 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



0
gsinclair1 (862)
8/28/2004 12:59:32 PM
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? :) 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.


0
transami (959)
8/28/2004 3:52:22 PM
On Sun, Aug 29, 2004 at 12:52:22AM +0900, T. Onoma wrote:
> 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

rpa-base has no capital letters ;)

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

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.

-- 
Running Debian GNU/Linux Sid (unstable)
batsman dot geo at yahoo dot com



0
batsman.geo (482)
8/28/2004 6:50:05 PM
[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,


0
8/28/2004 7:15:30 PM
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)

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

-- 
Running Debian GNU/Linux Sid (unstable)
batsman dot geo at yahoo dot com



0
batsman.geo (482)
8/28/2004 7:57:32 PM
Reply:
Similar Artilces: