Cobbler

Shoes 3.2 (aka Federales) has a new screen for folks that like to tweak things. The link is available at the bottom of the splash screen or if using the command line ccoupe@pi ~ $ .shoes/federales/shoes -c. One obvious option is to list what is known about the running Shoes and Ruby. Here’s two screenshots after the Shoes Info button was pressed. Pay close attention to the differences. Here’s Shoes running on the Raspberry pi:
cobbler-info-pi

And here’s the result from Shoes Info button press on a ‘build from source’ on my Ubuntu 13.10 system
cobbler-info-x86

Differences? armhf vs x86_64. To be expected. Build dates are little different. Ruby version is slightly different. One of them has more buttons. How could the pi have more buttons than a build from scratch? Look more closely. One is TIGHT_SHOES and one is LOOSE_SHOES. There are more buttons for TIGHT_SHOES (Linux, OSX, and Windows) because tight shoes need more help. Tight shoes is what you get when you download (or package) a .run, .exe, or osx.tgz. Tight shoes is all sandboxed and can be redistibuted/copied just like Shoes 2 was (and Shoes 3.1 failed at). Loose Shoes can only be built from source and it can’t be copied across the net because it’s tigthly linked to the ruby it was compiled with — mine was at /home/ccoupe/.rvm/rubies/ruby-2.1.0 I’ll bet your ruby isn’t at that location so it would fail if you copied it across the network. Shoes 3.2 tries to prevent you from doing that.

Tight Shoes is for (re)distribution, Loose shoes is for when you don’t care about that and want the fastest compile and the smallest foot print. Loose Shoes will use the gem directories for what ever Ruby you built it with. There’s no built-in Ruby with Loose Shoes. For Linux, it also symlinks the shoes and samples directories so if your working on Shoes ruby code like app_packager.rb you don’t have to recompile Shoes c code just to test a ruby code change. I like it.

The Manage gems button allows you to install and remove gems from the Shoes gem directory. You don’t need a Shoes.setup block in your Shoes script. If you do want that, it will work much better than the older Shoes.

Most people will have/use Tight Shoes. The ability to use binary gems that don’t come with Shoes is missing. Cobbler has a button for that: “Jailbreak”. That allows you to enter the path to another gem directory that Shoes can use. To use that, you have to install the development tools and libraries for Ruby on your plaform. PITA for Windows (and OSX). The “Development Tools” button doesn’t work yet but if it did (it doesn’t), it would do that for you.

Clear Image Cache: Shoes has a cache of images that have been downloaded from the net. Sometimes you get a partial or old image stuck in the cache. This a blunt force option. Use it wisely.

Copy Sameples: Would you like to modify one of the sample scripts that the manual lists? Can’t find them on your Windows or OSX system or its too damn hard to navigate to where they live in secret directories? Create a copy of them where you can find them and edit them as you like without modifing the Shoes samples.

Packager URL’s:
cobble-packager

This is deep magic, folks. Refer to shoes/app_packager.rb to see how this works. Do not play here if you don’t understand what is happening and why packaging is cool but ultimately uselss. Seriously, don’t play here. OK, some of you still want to know what it can do and I’ll reluctantly tell you and when your head spins 720 degrees, you won’t blame me, OK?. The Shoes 3.2 packager builds it’s list of available platforms by quering the CGI Selectory url which returns a text file list of available Shoes. Each line includes the size in MB, the time stamp and the Shoes 3.2 peculiar file name that has all kinds of meta data implied in the name. I have a ruby cgi script at my website but it could be a static text file IN THE CORRECT FORMAT. For each platform that is presented and clicked by the user, the packager checks it’s cache of Shoes downloads and if it thinks the website is newer, it downloads that to the cache. If a newer version or equlivaent version is already in the cache then there is an dialog that allows to download to the cache. The cache will always package with the newest version of Shoes 3.2 for that platform. Then it unpacks (now cached) Shoes and repacks it to include your script/directory. You might notice that there is a download URL which can be a different site. Perheps the selector is a jekyll created static file and the download is from my site (or someone elses site). It can be done.

Is your head spinning yet? Did I mention that most of Cobbler and packager should run in Shoes 4? Not the Windows binject::exe stuff of course. There’s no reason that Shoes 4 couldn’t package a script for Raspberry pi Shoes 3.2 (or OSX or Linux 64) or vice versa. A 3.2 pi user might be able to package a script for Shoes 4. Like I’ve said many times before. Most people should not use packager but if you insist, Shoes 3.2 has options.

Leave a Reply

Your email address will not be published. Required fields are marked *