Forum: Ruby crate 0.1.1 Released

Announcement (2017-05-07): www.ruby-forum.com is now read-only since I unfortunately do not have the time to support and maintain the forum any more. Please see rubyonrails.org/community and ruby-lang.org/en/community for other Rails- und Ruby-related community platforms.
Jeremy H. (Guest)
on 2008-12-01 19:19
(Received via mailing list)
I'm pleased to announce that Crate, the project I spoke on at RubyConf
this year, has reached a releasable stage.

  gem install crate

Crate is a tool to help package up your application as a custom static
build of the ruby interpreter plus all dependant binary extensions.
All the pure ruby code (the ruby application, the ruby stdlib, etc) is
packed into one or more SQLite databases.

The final distributable pieces are a single executable and a few SQLite
databases which can be then wrapped up appropriately as an OS X App; a
self extracting executable for Windows; a shar archive, rpm or tarball
for Unixes.

Project:  http://copiousfreetime.rubyforge.org/crate/
Tutorial:
http://copiousfreetime.org/articles/2008/11/30/pac...

enjoy,

-jeremy
Ezra Z. (Guest)
on 2008-12-01 21:27
(Received via mailing list)
On Dec 1, 2008, at 9:12 AM, Jeremy H. wrote:

> The final distributable pieces are a single executable and a few
> SQLite
> databases which can be then wrapped up appropriately as an OS X App; a
> self extracting executable for Windows; a shar archive, rpm or tarball
> for Unixes.
>
> Project:  http://copiousfreetime.rubyforge.org/crate/
> Tutorial: 
http://copiousfreetime.org/articles/2008/11/30/pac...



  This project is pure awesome, that is all.

Thanks
Ezra Z.
removed_email_address@domain.invalid
Avdi G. (Guest)
on 2008-12-01 21:33
(Received via mailing list)
On Mon, Dec 1, 2008 at 12:12 PM, Jeremy H.
<removed_email_address@domain.invalid> wrote:

> Crate is a tool to help package up your application as a custom static
> build of the ruby interpreter plus all dependant binary extensions.
> All the pure ruby code (the ruby application, the ruby stdlib, etc) is
> packed into one or more SQLite databases.

Stupid question: what's the advantage of using a SQLite DB over a
tarball or zip file?

--
Avdi

Home: http://avdi.org
Developer Blog: http://avdi.org/devblog/
Twitter: http://twitter.com/avdi
Journal: http://avdi.livejournal.com
Jeremy H. (Guest)
on 2008-12-01 22:18
(Received via mailing list)
On Tue, Dec 02, 2008 at 04:26:39AM +0900, Avdi G. wrote:
> On Mon, Dec 1, 2008 at 12:12 PM, Jeremy H.
> <removed_email_address@domain.invalid> wrote:
>
> > Crate is a tool to help package up your application as a custom static
> > build of the ruby interpreter plus all dependant binary extensions.
> > All the pure ruby code (the ruby application, the ruby stdlib, etc) is
> > packed into one or more SQLite databases.
>
> Stupid question: what's the advantage of using a SQLite DB over a
> tarball or zip file?

Stupid answer: I really have no idea.  I didn't even think about it.

One of the requirements I set for myself on this one was that there
would be no 'unpacking' of the ruby source code onto the deployed file
system.   That, and I just like the idea of requiring ruby code that is
really a row in an sqlite database :-).

You could overwrite require to open up an archive file of some format
and load the ruby file, and I see no reason why someone shouldn't write
that.  Rubyscript2exe takes this appraoch, and unpacks the .rb files to
the file system.

Off the top of my head, the main advantage I see of using sqlite over
zip/tar file is your application gets the free bonus of having a built
in relation database with no extra cost.

There may be some performance advantage for require in that it only has
to do a select from a db, vs open up .zip file for ever require, but I
won't consider that a valid argument at this point.

enjoy,

-jeremy
Jeremy H. (Guest)
on 2008-12-01 22:23
(Received via mailing list)
On Tue, Dec 02, 2008 at 04:21:05AM +0900, Ezra Z. wrote:
>> All the pure ruby code (the ruby application, the ruby stdlib, etc) is
>
>
>
>   This project is pure awesome, that is all.
>

Thank you Ezra.  I happen to think so too :-).

enjoy,

-jeremy
Luis L. (Guest)
on 2008-12-02 04:10
(Received via mailing list)
On Dec 1, 3:12 pm, Jeremy H. <removed_email_address@domain.invalid> wrote:
> > tarball or zip file?
> that.  Rubyscript2exe takes this appraoch, and unpacks the .rb files to
> the file system.
>
> Off the top of my head, the main advantage I see of using sqlite over
> zip/tar file is your application gets the free bonus of having a built
> in relation database with no extra cost.
>
> There may be some performance advantage for require in that it only has
> to do a select from a db, vs open up .zip file for ever require, but I
> won't consider that a valid argument at this point.  
>

Sorry to bring this, but Python packages the standard library and your
application into zip files.

It maps the File requests that deal with files to the zip file, which
the handler is open once and keep opened until the application ends.

There is one problem with this which is search for the proper
requirement, which I guess having a sqlite engine backing up will make
it easy.

I'll need to check it out how it works with gems that depends on
extensions, since dlopen / LoadLibrary needs a real file and cannot
map a memory address to load the symbols (just thinking out loud here,
maybe you already figured this out).

> enjoy,
>

BTW: great release!

Regards,
Jeremy H. (Guest)
on 2008-12-02 10:02
(Received via mailing list)
On Tue, Dec 02, 2008 at 11:04:32AM +0900, Luis L. wrote:
> On Dec 1, 3:12?pm, Jeremy H. <removed_email_address@domain.invalid> wrote:

[...]
> the handler is open once and keep opened until the application ends.
Cool, I didn't know that.  And I see that the rubyzip library does
override
require and that might another option for a future crate.

> There is one problem with this which is search for the proper
> requirement, which I guess having a sqlite engine backing up will make
> it easy.
>
> I'll need to check it out how it works with gems that depends on
> extensions, since dlopen / LoadLibrary needs a real file and cannot
> map a memory address to load the symbols (just thinking out loud here,
> maybe you already figured this out).

You might call it cheating, what I do is clear out $LOAD_PATH after
initializing the interpreter and before handing off control to the
wrapped up ruby application.  The require order is then, the ruby
original require followed by the amalgalite overridden require.

That way, if the require is a loaded module (which is now statically
compiled in) the ruby internal rb_require() will return success, and if
it is a .rb file LoadError will be raised and then amalgalite will take
care of loading the appropriate file from the sqlite database.

This is the same approach used by rubygems.

What this means for a crate application is that mixing filesystem .rb
files with those stored in sqlite databases may cause odd behavior if
something fiddles with $LOAD_PATH.

> BTW: great release!

Thanks!

enjoy,

-jeremy
Joel VanderWerf (Guest)
on 2008-12-02 23:18
(Received via mailing list)
Jeremy H. wrote:
> On Tue, Dec 02, 2008 at 11:04:32AM +0900, Luis L. wrote:
...
> That way, if the require is a loaded module (which is now statically
> compiled in) the ruby internal rb_require() will return success, and if
> it is a .rb file LoadError will be raised and then amalgalite will take
> care of loading the appropriate file from the sqlite database.

So, still wondering about Luis's question... how do you load extensions?
Jeremy H. (Guest)
on 2008-12-03 04:10
(Received via mailing list)
On Wed, Dec 03, 2008 at 06:12:53AM +0900, Joel VanderWerf wrote:
>> original require followed by the amalgalite overridden require.  That way,
>> if the require is a loaded module (which is now statically
>> compiled in) the ruby internal rb_require() will return success, and if
>> it is a .rb file LoadError will be raised and then amalgalite will take
>> care of loading the appropriate file from the sqlite database.
>
> So, still wondering about Luis's question... how do you load extensions?

Crate applications are standalone applications.  There is no loading of
extensions per se.  When you package your ruby application with crate
you
compile in all the necessary extensions statically.  They are all
initialized
when the interpreter starts.

An issue arises when, in your .rb files, you have a "require 'zlib'" or
some
other require that would in a standard ruby execution would dynamically
load an
extension.  In a crate packaged application, this is really a noop
because the
extension is already loaded, since it is comopiled in, but the require
statement
needs to not throw a LoadError.

By having the built in require (rb_require()) attempt first, it
essentially does
this noop and does not throw the LoadError, and the application goes
ahead and
uses the classes that it wants.  And the issue is gone.

Make sense?

enjoy,

-jeremy
Luis L. (Guest)
on 2008-12-03 04:25
(Received via mailing list)
On Dec 2, 4:12 pm, Joel VanderWerf <removed_email_address@domain.invalid> wrote:
> > wrapped up ruby application.  The require order is then, the ruby
> > original require followed by the amalgalite overridden require.  
>
> > That way, if the require is a loaded module (which is now statically
> > compiled in) the ruby internal rb_require() will return success, and if
> > it is a .rb file LoadError will be raised and then amalgalite will take
> > care of loading the appropriate file from the sqlite database.
>
> So, still wondering about Luis's question... how do you load extensions?
>

I got my answer looking at Jeremy presentation at RubyConf.

Basically you "integrate" the gem C extension into ruby itself, so
there is no need to carry the .so files around.

The only problem with that approach is you need to install all the
required dependencies to build those extensions, and have some gems
developers play nice in their extconf.rb files too.

Yet still, the ruby interpreter is quite capable of loading the .so
files form the file system if they existed.

Regards,
This topic is locked and can not be replied to.