Crown 1.0.0

Quoting the README at http://github.com/vjoel/crown/tree/master :

The crown program gathers gem lib and bin files under one directory
for fast loading and predictable behavior. For example:

[~/tmp] crown -v mygems json nokogiri sinatra
sinatra-0.9.4
nokogiri-1.3.3
json-1.1.7
rack-1.0.0
PATH=/home/vjoel/tmp/mygems/bin

RUBYLIB=/home/vjoel/tmp/mygems/ext:/home/vjoel/tmp/mygems/ext/json/ext:/home/vjoel/tmp/mygems/lib

The gems are copied under mygems:

[~/tmp] ls mygems
bin ext lib
[~/tmp] ls mygems/lib
action-nokogiri.rb json.rb nokogiri.rb rack.rb sinatra.rb
json nokogiri rack sinatra xsd

The output of ‘crown -v’ shows you which gems (and versions) it is
gathering, including all dependencies, and it shows you the PATH and
RUBYLIB you need to use those files:

[~/tmp] export RUBYOPT=’’
[~/tmp] export
RUBYLIB=/home/vjoel/tmp/mygems/ext:/home/vjoel/tmp/mygems/ext/json/ext:/home/vjoel/tmp/mygems/lib
[~/tmp] ruby -r json -e ‘p JSON’
JSON

Why?

  • You can stop requiring ‘rubygems’ and you don’t need
    RUBYOPT=‘rubygems’. There are no runtime dependencies on rubygems.

  • Lookups for required files should be faster.

  • No chance that “gem update” or “gem cleanup” might break your program.

  • You can distribute the “crown of gems” with your program.

Features:

  • Either symlink files (-s switch) or copy files (the default).

  • Include other non-gem files using dest:file syntax.

  • Existing files in the target dir are not touched if they are not in
    the way.

  • Works correctly even with gems that have strange require_path lists,
    like json.

  • No dirs are ever deleted or replaced.

  • A file is written only if either it doesn’t already exist in the
    target dir or you specify the force (-f) switch.

  • The verify (-V) mode checks whether the target dir looks like it has
    had the crown command run on it with the given arguments.

  • Dry-run (-n) and verbose (-v, -vv) options, as in FileUtils

See the help (-h) for details, license, version, and contact
information.

This software is not fully tested on all gems; please test carefully
before using in production environments.

On Aug 19, 2009, at 20:21 , Joel VanderWerf wrote:

PATH=/home/vjoel/tmp/mygems/bin
RUBYLIB=/home/vjoel/tmp/mygems/ext:/home/vjoel/tmp/mygems/ext/json/
ext:/home/vjoel/tmp/mygems/lib

The gems are copied under mygems:

[~/tmp] ls mygems
bin ext lib
[~/tmp] ls mygems/lib
action-nokogiri.rb json.rb nokogiri.rb rack.rb sinatra.rb
json nokogiri rack sinatra xsd

that’s pretty cool!

you might consider making this a gem plugin and or merging it into
rubygems straight up. I think the latter has serious merit.

Ryan D. wrote:

that’s pretty cool!

you might consider making this a gem plugin and or merging it into
rubygems straight up. I think the latter has serious merit.

I guess the downside is, you can’t have multiple versions of the same
gem available at once?

I guess if each application or project has its own tree of symlinks or
copies of the gems, that’s fine.

On Aug 20, 2009, at 01:17 , Brian C. wrote:

copies of the gems, that’s fine.
That’s exactly the point of crown as I see it.

Ryan D. wrote:

that’s pretty cool!

you might consider making this a gem plugin and or merging it into
rubygems straight up. I think the latter has serious merit.

Thanks! I will look into gem plugins…

Ryan D. wrote:

On Aug 20, 2009, at 01:17 , Brian C. wrote:

I guess the downside is, you can’t have multiple versions of the same
gem available at once?

I guess if each application or project has its own tree of symlinks or
copies of the gems, that’s fine.

That’s exactly the point of crown as I see it.

Right. It would be a problem if, for example, your project contains two
executables which depend on different gem versions. Crown barfs if you
include two versions of the same gem.[1]

Currently, I’m using this to give production and development trees their
own gem environments that don’t change when gem update happens. At well
defined intervals, we can re-crown development to pull in the latest
gems. When it’s time to migrate dev to pro, we just pull the crown along
with it.

This would also be possible by specifying gem versions explicitly in the
source, but that seems harder to automate. Also, by not using rubygems’
require we can be sure that there are no unmanaged dependencies.

[1]
$ crown cr narray=0.5.9.7 narray=0.5.9.6
Replication target for
/usr/local/lib/ruby/gems/1.8/gems/narray-0.5.9.6/./src/ChangeLog exists
and is different: cr/./src/ChangeLog

This forum is not affiliated to the Ruby language, Ruby on Rails framework, nor any Ruby applications discussed here.

| Privacy Policy | Terms of Service | Remote Ruby Jobs