Re: Call for standardised package installation procedure

I admit I haven't the last four emails in this thread but I can't help 
myself, I must butt in :)
If I remember correctly the whole thread started with a request for a 
common way to install ruby programs/libraries.
As I mentioned before, having to little experience with C extensions I 
will leave them out for the moment. I will start first with the pure 
ruby libs that go into the site directory.
My impression is that high in the wish list (and helpful to most 
newbies) would be a package that offers a unified and easy (if error 
free or less error prone) way to put the ruby libraries where they belong.
That means put them in

CONFIG["sitedir"] or CONFIG["sitelibdir"] or CONFIG["sitearchdir"]
(taken from rbconfig.rb)
and make sure all require statements are fullfiled. For starters let the 
user find and install the packages that are required.

Going one step further, it would be nice to have some tool that can 
create such an install script for the developer.
That would be step one.
Step two can build on such a tool by making it "ruby repository" aware. 
That, for me, means that such an autogenerated script looks for 
repository support in the ruby installation and adds an entry (and such 
a repository has a tool to query for already installed packages)
Having a clearly defined interface for these two would help OS package 
maintainers to get the information they need to maintain ruby-package 
distributions. I personally use Gentoo, Tom you can scream if I'm 
talking rubish, and I don't think adapting an ebuild to pass data from a 
ruby script to Portage is such a big deal - provided there is a unified 
way to keep such information :). But, again, this would come as a third 
step in my list.
Since the thread started I played around with a few ideas and put 
together some code yesterday. Unfortunately I have not had the time to 
complete the functionality, nor have I any way to host this ultra alpha 
version so that you could look at it.
So I'll simply attach it to this email and whoever is interested can 
take a look at it.
First let me say that I would like to take the time and check Minero 
Aoki's setup.rb. Second, let's just say I'm too new with Ruby to be able 
to write really effective code.
Third, here's the central idea for this:

It consists of two parts:
Part one is the creator:
Given a structure like the following:

/----src/
   |--doc/
   |--foo/

running the createinstall script with a package name parameter in / will 
create a directory called distro that contains the above structure, so 
we have
  /---src/
    |-doc/
    |-foo/
    |-distro/package
        		|----src/
        		|----doc/
        		|----bla/

Now, the ruby files are in src/ and the creator script has generated a 
script called distro/rbinstall.rb
This rbinstall.rb has some command line parameters and essentially does 
the following:
Checks in all files in /src for require statements and then traverses 
the rubylib, archdir, sitearchdir, sitelibdir and sitedir directories 
for .rb files that match the require parameters.
If everything found is matched then it copies the contents of src/ under
one of the sitearchdir, sitelibdir and sitedir directories depending on 
what was specified in createinstall (dependencies for architecture 
and/or version).

The way the rbinstall.rb script is generated is actually a hack:
The actual class, the script and the required module are put together 
from files in the creatorinstall library (putting the module in the file 
instead of require'ing it ensures it will be there, and it will be the 
version the script expects it to be). The createinstall.rb just fills in 
a "header" for the generated file with constants whose values are used 
by the script file.

I have coded (more or less) the following:
(This is in no way complete - it's a day's coding with three weeks 
experience in Ruby - feel free to deride/curse/roll eyes. This also 
means that the code is in a look-but-don't-run state. I promise, 
*really*, that I'll have a runable version by the end of the week, 
unless I get booed by everyone in this list)

creator.rb:
This is the class that creates the distro directory and the installer 
script. It is clever enough to look for it's own files (rbinstall.rb, 
script.rb and requirements.rb) in the libraries or under the current 
directory.

requirements.rb
This is a module that adds a method for finding the contents of require 
statements in all files under a directory and a method for matching that 
list from all files in the ruby libraries. Uses rbconfig.rb to find the 
directories.

rbinstall.rb
This defines a class that does the basic install sequence (actually 
copies the files :) ). I need to test it - didn't have enough time to 
finish it yesterday.

script.rb
This is the part of the installer script that executes. Here are the 
command line parameters defined and handled, the RBINSTALL class 
instantiated etc. This needs a bit more work. It should use rbconfig.rb 
to check  architecture and/or ruby version requirements

What's missing:

createinstaller.rb where the command line parameters are passed to the 
creator class and everything is put together.
Nothing is tested, there is no documentation and I'm not even sure this 
is proper ruby.

I am pretty confident that I can make this "self-hosting" from day one 
(ok day three, days one and two are already gone :) ). This means that 
this package can distribute and install itself.

What can be done:
Wow, after reading most of the thread I can imagine a lot of things, but 
I will contain myself to the following:

*Extend the functionality to handle C extensions.
*Add support for a ruby repository (as a library withing this 
package). 	   This can be easily made optional. When such functionality 
is there, then we can also talk about a scheme for versioning packages.
*For missing requirements go to RAA and suggest packages for download.

Like I said, easy does it. For me the number one priority is to built a 
tool that simplifies deployment within Ruby and then buildng on that to 
add ways to be used by external tools.
Phew, that was a long email :P
V.-



--
http://www.freemail.gr - 糯驟橄 苟纉焉 芫繩闕蜉陜 糀闌縷阨.